この節では、2 つのシステム間のトラフィックを保護し、Web サーバーを保護し、仮想プライベートネットワークをセットアップするための手順について説明します。システム名 enigma と partym は一例として説明しているだけです。よって、enigma と partym を各自使用しているシステムの名前に置き換えてください。
役割を使って IPsec を管理する方法については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (手順)」を参照してください。
この手順では、次の設定がすでになされているものとします。
各システムには、2 つのアドレス (IPv4 アドレスと IPv6 アドレス) がある
各システムは、128 ビットのキーを必要とする MD5 アルゴリズムを使って AH 保護を呼び出す
各システムは、192 ビットのキーを必要とする 3DES アルゴリズムを使って ESP 保護を呼び出す
IPsec は、共有セキュリティアソシエーションを使用する
共有セキュリティアソシエーションでは、2 つのシステムを保護するのに 1 組だけの SA を必要とします。
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
システムごとに、他のシステムのアドレスとホスト名を /etc/inet/ipnodes ファイルに追加します。次のように、1 つのシステムのエントリは連続してそのファイルに入力します。
partym という名前のシステムでは、ipnodes ファイルに次のように入力します。
# Secure communication with enigma 192.168.116.16 enigma fec0::10:20ff:fea0:21f6 enigma |
enigma という名前のシステムでは、ipnodes ファイルに次のように入力します。
# Secure communication with partym 192.168.13.213 partym fec0::9:a00:20ff:fe7b:b373 partym |
システムの名前は、一例として使用しているだけです。実際にシステム間のトラフィックを保護する場合には、各自のシステムの名前を使用してください。
これで、起動スクリプトでは、存在しないネーミングサービスに依存することなくシステム名を使用できます。
システムごとに、/etc/inet/ipsecinit.conf ファイルを作成します。
/etc/inet/ipsecinit.sample ファイルを /etc/inet/ipsecinit.conf にコピーすることができます。
ipsecinit.conf ファイルに IPsec ポリシーエントリを追加します。
システムごとに、2 つのシステム間の IPsec セキュリティアソシエーションの組を追加します。
システムごとに、読み取り専用の /etc/inet/secret/ipseckeys ファイルを編集します。読み取り専用ファイルのアクセス権は 400 です。ipseckeys ファイル で、ESP 保護と AH 保護のセキュリティアソシエーションの組は、次の形をとります。
add protocol spi random-hex-string dst local-system \ encr_alg protocol-algorithm \ encrkey random-hex-string-of-algorithm-specified-length add protocol spi random-hex-string dst local-system \ auth_alg protocol-algorithm \ authkey random-hex-string-of-algorithm-specified-length add protocol spi random-hex-string dst remote-system \ encr_alg protocol-algorithm \ encrkey random-hex-string-of-algorithm-specified-length add protocol spi random-hex-string dst remote-system \ auth_alg protocol-algorithm \ authkey random-hex-string-of-algorithm-specified-length |
protocol |
esp または ah。ah プロトコルでは、auth_alg と authkey 引数を使用する。esp プロトコルでは、encr_alg と encrkey 引数も使用する。esp では、さらに、ah で使用する auth_alg と authkey 引数も使用する |
random-hex-string |
16 進数形式の最大 8 桁の乱数。SPI が受け取れる以上の桁数を入力すると、超過部分は無視される。SPI が受け取れるより少ない桁数を入力すると、パディングが行われる |
local-system |
ローカルシステム名 |
remote-system |
リモートシステム名 |
protocol-algorithm |
ESP または AH のアルゴリズム。それぞれのアルゴリズムには、特定の長さのキーが必要 認証アルゴリズムには MD5 と SHA がある。暗号化アルゴリズムには 3DES と AES がある |
random-hex-string-of-algorithm-specified-length |
アルゴリズムによって必要とされる長さをもつ 16 進数の乱数。たとえば、MD5 アルゴリズムでは、128 ビットキーのため 32 桁の乱数が必要。3DES アルゴリズムでは、192 ビットキーのため 48 桁の乱数が必要 |
乱数を生成します。
アウトバウンドトラフィックとインバウンドトラフィックにはそれぞれ、3 種類の乱数が必要です。したがって、システムごとに次の乱数が必要になります。
spi キーワードの値として、2 つの 16 進数の乱数。1 つの乱数はアウトバウンドトラフィック用、もう 1 つの乱数はインバウンドトラフィック用。それぞれの乱数の最大桁数は 8 桁
AH の MD5 アルゴリズム用として、2 つの 16 進数の乱数。各乱数は 32 桁でなければならない。1 つの乱数は dst enigma 用、もう 1 つの乱数は dst partym 用
ESP の 3DES アルゴリズム用として、2 つの 16 進数の乱数。192 ビットキーの場合、各乱数は48 桁でなければならない。1 つの乱数は dst enigma 用、もう 1 つの乱数は dst partym 用
乱数発生関数がすでにある場合は、それを使用してください。ない場合は、od コマンドを使用できます。この手順については、乱数を生成する方法を参照してください。
たとえば、enigma では、ipseckeys ファイルの内容は次のようになります。
# for inbound packets add esp spi c83f5a4b dst enigma encr_alg 3DES \ encrkey b6a8f89213a796bde03c601029861eae91c65783368165a6 # add ah spi 2f526ae6 dst enigma auth_alg MD5 authkey 305ec56369ca62c2ae804690c5713e18 # for outbound packets add esp spi 0cecc4b2 dst partym encr_alg 3DES \ encrkey 802e89f9f9b929ea2b615641b71ac7034a540d3cbeeaf6a9 # add ah spi a75bbe5f dst partym auth_alg MD5 \ authkey 2ae8b94967e6b9b0dd16e6d4b7ea7278 |
partym の ipseckeys には、同一のキーを使用します。コメントが異なっていますが、これは、dst enigma が enigma ではインバウンド、partym ではアウトバウンドであるためです。
# for outbound packets add esp spi c83f5a4b dst enigma encr_alg 3DES \ encrkey b6a8f89213a796bde03c601029861eae91c65783368165a6 # add ah spi 2f526ae6 dst enigma auth_alg MD5 authkey 305ec56369ca62c2ae804690c5713e18 # for inbound packets add esp spi 0cecc4b2 dst partym encr_alg 3DES \ encrkey 802e89f9f9b929ea2b615641b71ac7034a540d3cbeeaf6a9 # add ah spi a75bbe5f dst partym auth_alg MD5 \ authkey 2ae8b94967e6b9b0dd16e6d4b7ea7278 |
これらのキーと SPI は、セキュリティアソシエーションごとに変更できます。セキュリティアソシエーションごとに、異なるキーと異なる SPI を割り当てるべきです。
リブートします。
# /usr/sbin/reboot |
パケットが保護されているかどうかを確認するには、パケットが保護されていることを確認する方法を参照してください。
次の例では、IPv6 アドレスを持つシステム間の保護トラフィックをテストする方法について説明します。実際の稼動環境では、ipsecconf コマンドを実行するよりもリブートする方が安全です。
2 つのシステム間のトラフィックを保護する方法の手順 5 までを実行します。
リブートする代わりに、ipseckey コマンドを使ってセキュリティアソシエーションをデータベースに追加します。
# ipseckey -f /etc/inet/secret/ipseckeys |
次のように、ipsecconf コマンドを使用して IPsec ポリシーを有効にします。
# ipsecconf -a /etc/inet/ipsecinit.conf |
このコマンドの実行時には警告を読んでください。ソケットがすでに使用中 (ラッチされた) の場合には、システムのセキュリティが低下します。
次の例では、IPv4 アドレスを持つシステム間のトラフィックを保護する方法について説明します。この例では、自動キー管理 (IKE) を使用してセキュリティアソシエーションを作成します。IKE は、管理者が介在する必要が少なく、大量のトラフィックを容易に保護するようにスケーリングします。
前の手順の手順 2 の/etc/inet/ipnodes ファイルを /etc/hosts ファイルに置き換えます。
partym システムで、enigma を /etc/hosts ファイルに追加します。
# echo "192.168.116.16 enigma">> /etc/hosts |
enigma システムで、partym を /etc/hosts ファイルに追加します。
# echo "192.168.13.213 partym">> /etc/hosts |
ipsecinit.conf ファイルを編集して IPsec ポリシーエントリを追加します (手順 4 を参照)。
キーは、次のどちらかの方法で作成できます。
IKE を設定してキーを自動的に生成する。IKE はキーを自動的に更新します。IKE を設定するには、表 4–1 の設定手順のどれかに従ってください。IKE 設定ファイルの構文については、ike.config(4) のマニュアルページを参照してください。
キーの生成や保守を手動で行う必要が特にない場合は、IKE を設定すべきです。
IKE デーモン in.iked を起動しない場合は、キーを手動で作成できます。これについては、2 つのシステム間のトラフィックを保護する方法の手順 5 を参照してください。
リブートします。
リブートせずにトラフィックを保護する場合は、ipseckey コマンドと ipsecconf コマンドを使用します。
# ipseckey -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/ipsecinit.conf |
このコマンドの実行時には警告を読んでください。ソケットがすでに使用中 (ラッチされた) の場合には、システムのセキュリティが低下します。
パケットが保護されているかどうかを確認するには、パケットが保護されていることを確認する方法を参照してください。
セキュリティ保護された Web サーバーでは、Web クライアントであれば Web サービスと通信できます。セキュリティ保護された Web サーバーでは、Web トラフィック以外のトラフィックは、セキュリティ検査を通る必要があります。次の手順には、Web トラフィックの検査省略手順が含まれています。さらに、この Web サーバーでは、セキュリティ保護されていない DNS クライアント要求を出すことができます。その他のすべてのトラフィックでは、Blowfish と SHA-1 アルゴリズムによる ESP が必要です。他のトラフィックではさらに、アウトバウンドトラフィックに共有 SA を使用します。共有 SA を使用すると、生成しなければならないセキュリティアソシエーションの数が少なくて済みます。
システムコンソールから、スーパーユーザーになるか、同等の役割を引き受けます。
リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
セキュリティポリシー検査を省略するサービスを指定します。
Web サーバーの場合、TCP ポート 80 (HTTP) と 443 (保護 HTTP) が該当します。Web サーバーが DNS 名検査をするときは、TCP と UDP の両方にポート 53 も組み込む必要がある場合もあります。
Web サーバーポリシー用のファイルを /etc/inet/ ディレクトリに作成します。このファイルにその目的を表す名前を与えます (たとえば、IPsecWebInitFile)。このファイルに次のように入力します。
# Web traffic that Web server should bypass. {sport 80 ulp tcp} bypass {dir out} {dport 80 ulp tcp} bypass {dir in} {sport 443 ulp tcp} bypass {dir out} {dport 443 ulp tcp} bypass {dir in} # Outbound DNS lookups should also be bypassed. {dport 53} bypass {dir out} {sport 53} bypass {dir in} # Require all other traffic to use ESP with Blowfish and SHA-1. # Use a shared SA for outbound traffic, in order to avoid a # large supply of security associations. {} permit {encr_algs blowfish encr_auth_algs sha} {} apply {encr_algs blowfish encr_auth_algs sha sa shared} |
これで、保護トラフィックだけがシステムにアクセスできるようになります。ただし、先の手順で説明した、検査を省略するトラフィックは例外です。
先の手順で作成したファイルを /etc/inet/ipsecinit.conf に読み込みます。
# vi /etc/inet/ipsecinit.conf :r IPsecWebInitFile :wq! |
IPsecWebInitFile ファイルを読み取り専用アクセス権で保護します。
# chmod 400 IPsecWebInitFile |
リブートせずに Web サーバーを保護するために、ipseckey コマンドと ipsecconf コマンドを使用します。
# ipseckey -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/ipsecinit.conf |
このコマンドの実行時には警告を読んでください。ソケットがすでに使用中 (ラッチされた) の場合には、システムのセキュリティが低下します。
リブートすることもできます。システムをリブートすると、IPsec ポリシーがすべての TCP 接続に適用されます。リブート時に、IPsec ポリシーのファイルで指定したポリシーが TCP 接続でラッチされます。
これで、Web サーバーでは、Web サーバートラフィックとアウトバウンド DNS 要求と応答だけを処理するようになりました。他のサービスは、IPsec をリモートシステムで有効にしないと機能しません。
リモートシステムと Web サーバーの間で非 Web トラフィックを安全に通信したい場合は、両方のポリシーが一致していなければなりません。リモートシステムの ipsecinit.conf ファイルに次のポリシーが設定されていれば、リモートシステムと Web サーバーは安全に通信できます。
# Communicate with Web server about non-Web stuff # {} permit {encr_algs blowfish encr_auth_algs sha} {} apply {encr_algs blowfish encr_auth_algs sha sa shared} |
この手順では、インターネットで VPN を構築して組織内の 2 つのネットワークを接続する方法について説明します。また、そのネットワーク間のトラフィックを IPsec で保護する方法について説明します。
この手順は、2 つのシステム間のトラフィックを保護する方法 の手順を拡張するものです。この手順では、2 つのマシンを接続するだけでなく、これら 2 つのマシンに接続している 2 つのイントラネットを接続します。この手順における 2 つのマシンはゲートウェイとして機能します。
この手順では、次の設定がすでになされているものとします。
各システムが IPv4 アドレス空間を使用している
各システムには 2 つのインタフェースがある。hme0 インタフェースはインターネットに接続している。この例では、インターネット IP アドレスは 192.168 で始まる。hme1 インタフェースは社内の LAN (イントラネット) に接続している。この例では、イントラネット IP アドレスは 10 で始まる
各システムは、MD5 アルゴリズムを使って AH 保護を呼び出す。MD5 アルゴリズムには 128 ビットキーが必要
各システムは、3DES アルゴリズムを使って ESP 保護を呼び出す。3DES アルゴリズムには 192 ビットキーが必要
各システムは、インターネットに直接アクセスするルーターに接続できる
IPsec は、共有セキュリティアソシエーションを使用する
VPN については、仮想プライベートネットワークを参照してください。次の図は、この手順によって設定される VPN を表しています。
この手順では、次の構成パラメータを使用します。
パラメータ |
ヨーロッパ |
カリフォルニア |
---|---|---|
ホスト名 |
enigma |
partym |
システムイントラネットインタフェース |
hme1 |
hme1 |
システムインターネットインタフェース |
hme0 |
hme0 |
システムイントラネットアドレス (手順 8 の -point アドレスでもある) |
10.16.16.6 |
10.1.3.3 |
システムインターネットアドレス (手順 8 の -taddr アドレスでもある) |
192.168.116.16 |
192.168.13.213 |
インターネットルーターの名前 |
router-E |
router-C |
インターネットルーターのアドレス |
192.168.116.4 |
192.168.13.5 |
トンネル名 |
ip.tun0 |
ip.tun0 |
どれかのシステムのシステムコンソールで、スーパーユーザーになるか、同等の役割を引き受けます。
リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
次のコマンドを入力して IP 送信をオフにします。
# ndd -set /dev/ip ip_forwarding 0 |
IP 送信をオフにすると、このシステムを経由したネットワーク間のパケット送信ができなくなります。ndd コマンドについては、ndd(1M) のマニュアルページを参照してください。
次のコマンドを入力して IP の厳密宛先マルチホームをオンにします。
# ndd -set /dev/ip ip_strict_dst_multihoming 1 |
IP 厳密宛先マルチホームをオンにすると、システムの宛先アドレスに宛てたパケットは、正しい宛先アドレスに必ず到着します。
ndd コマンドを使用して IP 送信をオフにし、IP 厳密宛先をオンにすると、システムを流れるパケットの数は少なくなります。マルチホームによって、システムのアドレス宛のパケットを除き、パケットの流れがシャットダウンされるからです。システムアドレスの場合は、マルチホームによって、宛先 IP アドレスに対応するインタフェースに到着するパケットだけが送信されます。
必要に応じて次の手順を行い、Solaris システム上の大部分 (場合によってはすべて) のネットワークサービスを無効にします。
inetd.conf を編集し、重要なサービス以外のすべてのサービスを削除してから、次のコマンドを入力します。
# pkill -HUP inetd |
VPN ルーターは、ほとんどの入力要求を受け付けません。入力トラフィックを受信するすべてのプロセスを無効にする必要があります。たとえば、inetd.conf ファイルの一部をコメントにしたり、SNMP を停止したりします。あるいは、Web サーバーを保護する方法で使用したようなテクニックを使うこともできます。
重要なサービス以外のすべてのサービスを削除するための inetd.conf の編集をしていない場合は、次のコマンドを入力します。
# pkill inetd |
必要に応じて、次の例のようなコマンドを 1 つまたは複数入力して SNMP、NFS など他のインターネットサービスを無効にします。
# /etc/init.d/nfs.server stop # /etc/init.d/sendmail stop |
ネットワークサービスを無効にすると、IP パケットによるシステムへの妨害がなくなります。たとえば、SNMP デーモン、telnet、rlogin を最大限に活用できます。
システムごとに、2 つのシステム間のセキュリティアソシエーションの組を追加します。
IKE デーモンは、セキュリティアソシエーションを作成するように設定されていれば、セキュリティアソシエーションを自動的に作成します。VPN に IKE を設定するには、次のいずれかの手順を実行します。
システムで IPv6 アドレスを使用している場合には、手動でセキュリティアソシエーションを作成する必要があります。手順については、IPsec セキュリティアソシエーションを手動で作成する方法を参照してください。
システムごとに、/etc/inet/ipsecinit.conf ファイルを編集して VPN ポリシーを追加します。
たとえば、enigma で、ipsecinit.conf ファイルに次のエントリを入力します。
# LAN traffic can bypass IPsec. {laddr 10.16.16.6 dir both} bypass {} # WAN traffic uses ESP with 3DES and MD5. {} ipsec {encr_algs 3des encr_auth_algs md5} |
たとえば、partym で、ipsecinit.conf ファイルに次のエントリを入力します。
# LAN traffic can bypass IPsec. {laddr 10.1.3.3 dir both} bypass {} # WAN traffic uses ESP with 3DES and MD5. {} ipsec {encr_algs 3des encr_auth_algs md5} |
ipsec エントリは、リモートシステムがクリアパケットを送信してくるのを防止します。bypass エントリを指定すると、LAN に属するノードでは、VPN ルーターを、それが LAN の一部であるかのように扱うことができます。
(省略可能) これより高いレベルのセキュリティが必要な場合は、LAN bypass エントリを削除します。
ipsecinit.conf のエントリは次のようになります。
# All traffic uses ESP with 3DES and MD5. {} ipsec {encr_algs 3des encr_auth_algs md5} |
これによって、LAN 上の各システムが VPN ルーターと通信するには、IPsec の起動が必要になります。
システムごとに、保護トンネル ip.tun0 を設定します。
このトンネルは、IP から見たもう 1 つの物理的インタフェースを追加します。3 つの ifconfig コマンドを入力してポイントツーポイントインタフェースを作成します。
# ifconfig ip.tun0 plumb # ifconfig ip.tun0 system1-point system2-point \ tsrc system1-taddr tdst system2-taddr encr_algs 3DES encr_auth_algs MD5 # ifconfig ip.tun0 up |
たとえば、enigma で次のコマンドを入力します。
# ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.16.16.6 10.1.3.3 \ tsrc 192.168.116.16 tdst 192.168.13.213 encr_algs 3DES encr_auth_algs MD5 # ifconfig ip.tun0 up |
たとえば、partym で次のコマンドを入力します。
# ifconfig ip.tun0 plumb # ifconfig ip.tun0 10.1.3.3 10.16.16.6 \ tsrc 192.168.13.213 tdst 192.168.116.16 encr_algs 3DES encr_auth_algs MD5 # ifconfig ip.tun0 up |
ifconfig コマンドに渡すポリシーは、ipsecinit.conf ファイルに指定されているポリシーと同じでなければなりません。リブート時に、各システムは ipsecinit.conf ファイルに指定されているポリシーを使用します。
システムごとに、hme1 と ip.tun0 インタフェースの ip_forwarding をオンにします。
# ndd -set /dev/ip hme1:ip_forwarding 1 # ndd -set /dev/ip ip.tun0:ip_forwarding 1 |
ip_forwarding は、別のインタフェースから到着したパケットを転送できることを意味します。ip_forwarding はまた、送信するパケットがもともとは別のインタフェースから発信されたパケットである可能性も、意味します。パケットを正しく転送するには、受信インタフェースと送信インタフェースの ip_forwarding をオンにしておきます。
hme1 インタフェースはイントラネットの内部にあるため、hme1 のip_forwarding はオンにしておきます。さらに、ip.tun0 はインターネットを通してこれら 2 つのシステムに接続されているため、ip.tun0 のip_forwarding はオンにしておきます。
hme0 インタフェースの ip_forwarding はオフです。そのため、外部からパケットが保護イントラネットに侵入するのを防ぐことができます。外部とはインターネットを意味します。
システムごとに、次のコマンドを入力して、ルーティングプロトコルによってイントラネット内のデフォルトのルートが通知されないようにします。
# ifconfig hme0 private |
hme0 の ip_forwarding がオフになっていても、ルーティングプロトコルの実装によっては、このインタフェースを通知することがあります。たとえば、in.routed プロトコルは、イントラネット内のピアにパケットが転送される際に hme0 を有効なインタフェースとして通知する場合があります。インタフェースの private フラグを設定すれば、このような通知を防止できます。
hme0 経由のデフォルトルートを手動で追加します。
このルートは、インターネットに直接アクセスできるルーターでなければなりません。
# pkill in.rdisc # route add default router-on-hme0-subnet |
たとえば、enigma で次のルートを追加します。
# pkill in.rdisc # route add default 192.168.116.4 |
partym で次のルートを追加します。
# pkill in.rdisc # route add default 192.168.13.5 |
hme0 インタフェースはイントラネットの一部ではありませんが、インターネットを介してそのピアシステムにアクセスする必要があります。hme0 は、自身のピアを見つけるために、インターネットルーティング情報を必要とします。インターネットの残りの要素にとって、VPN システムは、ルーターというよりもホストのような存在です。したがって、デフォルトルーターを使用するか、ルーター発見プロトコルを実行すれば、ピアシステムを見つけることができます。詳細については、route(1M) と in.routed(1M) のマニュアルページを参照してください。
リブート後に hme0 がデフォルトルートを使用するように、defaultrouter ファイルを作成します。
/etc/defaultrouter ファイルに hme0 のデフォルトルーターの IP アドレスを入力します。この手順により、in.rdisc デーモンがリブート時に起動しなくなります。
システムごとに、ブートシーケンスの初期にルーティングが起こらないようにします。これによって、セキュリティの脆弱性が軽減されます。
# touch /etc/notrouter |
VPN がリブート後に開始するように、/etc/hostname.ip.tun0 ファイルを編集します。
system1-point system2-point tsrc system1-taddr \ tdst system2-taddr encr_algs 3des encr_auth_algs md5 up |
システムごとに、VPN パラメータの一部をブート時に設定するファイルを作成します。このファイルに /etc/rc3.d/S99vpn_setup という名前を付け、次のように入力します。
ndd -set /dev/ip hme1:ip_forwarding 1 ndd -set /dev/ip ip.tun0:ip_forwarding 1 ifconfig hme0 private in.routed |
in.routed を使用する代わりに、手動で /etc/rc3.d/S99vpn_setup ファイルにルートを追加することもできます。
システムごとに、次のコマンドを入力してルーティングプロトコルを実行します。
# in.routed |
乱数発生関数がすでにある場合は、それを使用してください。ない場合は、Solaris の /dev/random デバイスを入力として od コマンドを実行することができます。詳細は、od(1) のマニュアルページを参照してください。
ランダムなキーを生成します。
Solaris システムでは、od コマンドを使用できます。
# od -X -A n file |
-x |
8 進数ダンプを 16 進数形式で表示する。16 進数形式はキー情報を表すのに役立つ。16 進数を 4 文字単位で表示する |
-X |
8 進数ダンプを 16 進数形式で表示する。16 進数を 8 文字単位で表示する |
–A n |
表示から入力オフセットベースを取り除く |
file |
乱数のソース |
たとえば、次のコマンドを入力すると、16 進数の乱数がそれぞれ次のように表示されます。
# od -X -A n /dev/random | head -2 d54d1536 4a3e0352 0faf93bd 24fd6cad 8ecc2670 f3447465 20db0b0c c83f5a4b # od -x -A n /dev/random | head -2 34ce 56b2 8b1b 3677 9231 42e9 80b0 c673 2f74 2817 8026 df68 12f4 905a db3d ef27 |
これらの乱数を組み合わせて、適切な長さのキーを作成します。
同じ行にある乱数間のスペースを取り除き、32 文字のキーを作成します。32 文字キーの長さは 128 ビットです。SPI の場合は、8 文字の乱数 1 個を使用できます。
システムで IPv6 アドレスを使用している場合には、手動で IPsec セキュリティアソシエーションを作成する必要があります。
IPv4 ネットワークを使用している場合は、IKE を使ってセキュリティアソシエーションを管理します。IKE を使って SA を管理する方法については、IKE の実装 (作業マップ)を参照してください。
どれかのシステムのシステムコンソールで、スーパーユーザーになるか、同等の役割を引き受けます。
リモートログインすると、セキュリティ上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システム全体のセキュリティがリモートログインセッションレベルに低下します。
次のコマンドを入力して ipseckey コマンドモードを有効にします。
# ipseckey > |
> プロンプトは、ipseckey コマンドモードになったことを示します。
セキュリティアソシエーションを作成したり、フラッシュしたばかりのセキュリティアソシエーションを置き換えたりするには、次のコマンドを実行します。
> add protocol spi random-hex-string \ src addr dst addr2 \ protocol_alg protocol-algorithm \ protocolkey random-hex-string-of-algorithm-specified-length |
random-hex-string |
16 進数形式の最大 8 桁の乱数。SPI が受け取れる以上の桁数を入力すると、超過部分は無視される。SPI が受け取れるより少ない桁数を入力すると、パディングが行われる |
protocol |
esp または ah |
addr |
システムの IP アドレス |
addr2 |
addr のピアシステムの IP アドレス |
protocol-algorithm |
ESP または AH のアルゴリズム。それぞれのアルゴリズムには、特定の長さのキーが必要 認証アルゴリズムには MD5 と SHA がある。暗号化アルゴリズムには 3DES と AES がある |
random-hex-string-of-algorithm-specified-length |
アルゴリズムによって必要とされる長さをもつ 16 進数の乱数。たとえば、MD5 アルゴリズムでは、128 ビットキーのため 32 桁の乱数が必要。3DES アルゴリズムでは、192 ビットキーのため 48 桁の乱数が必要 |
たとえば、enigma で、次のコマンドを入力してアウトバウンドパケットを保護します。生成した乱数を使用します。
> add esp spi 8bcd1407 src 192.168.116.16 dst 192.168.13.213 \ encr_alg 3DES \ encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d > add ah spi 18907dae src 192.168.116.16 dst 192.168.13.213 \ auth_alg MD5 \ authkey e896f8df7f78d6cab36c94ccf293f031 > |
ピアシステムでは、同じキー情報を使用する必要があります。
引き続き ipseckey モードを使って、enigma で、次のコマンドを入力してインバウンドパケットを保護します。生成した乱数を使用します。
> add esp spi 122a43e4 src 192.168.13.213 dst 192.168.116.16 \ encr_alg 3des \ encrkey dd325c5c137fb4739a55c9b3a1747baa06359826a5e4358e > add ah spi 91825a77 src 192.168.13.213 dst 192.168.116.16 \ auth_alg md5 \ authkey ad9ced7ad5f255c9a8605fba5eb4d2fd > |
これらのキーとSPI は、セキュリティアソシエーションごとに変更できます。セキュリティアソシエーションごとに、異なるキーと異なる SPI を割り当てるべきです。
Control-D か quit を使って ipseckey コマンドモードを終了します。
リブート時に IPsec がキー情報を使用できるように、enigma の /etc/inet/secret/ipseckeys ファイルにキー情報を追加します。
add esp spi 8bcd1407 dst partym encr_alg 3DES \ encrkey d41fb74470271826a8e7a80d343cc5aae9e2a7f05f13730d # add ah spi 18907dae dst partym auth_alg MD5 \ authkey e896f8df7f78d6cab36c94ccf293f031 # # add esp spi 122a43e4 dst enigma encr_alg 3DES \ encrkey 137fb4739a55c9b3a1747baa06359826a5e4358e # add ah spi 91825a77 dst enigma auth_alg MD5 \ authkey ad9ced7ad5f255c9a8605fba5eb4d2fd |
両システムのキー情報は同じでなければなりません。
暗号化システムを破る時間的な猶予を与えないためには、キー情報を更新する必要があります。あるシステムの SA を置き換える場合は、それと通信しているシステムの SA も置き換える必要があります。
セキュリティアソシエーションを置き換える場合は、古いキーを削除してから新しいキーを追加します。古いキーを削除するには、ipseckey コマンドモードで flush コマンドを実行します。そのあとに新しいキー情報を追加します。
# ipseckey > flush > add esp spi … |
パケットが保護されていることを確認するには、snoop コマンドで接続をテストします。snoop 出力に表示される接頭辞は、次のとおりです。
AH: 接頭辞 – AH がヘッダーを保護していることを示す。AH: が表示されるのは、auth_alg を使ってトラフィックを保護している場合
ESP: 接頭辞 – 暗号化されたデータが送信されていることを示す。ESP: が表示されるのは、encr_auth_alg か encr_alg を使ってトラフィックを保護している場合
snoop 出力を読むためには、root であるか、それと同等の役割でなければなりません。さらに、接続をテストするためには、両方のシステムにアクセスできなければなりません。
一方のシステム (たとえば、partym) で root になります。
% su Password: root-password # |
端末ウィンドウで、別のシステム (たとえば、enigma) から来るパケットの snoop を開始します。
# snoop -v enigma Using device /dev/hme (promiscuous mode) |
別の端末ウィンドウで、enigma システムにリモートからログオンします。パスワードを入力します。次に、root になり、enigma からのパケットを partym システムに送信します。
% rlogin enigma Password: your-password % su Password: root-password # ping partym |
partym の snoop ウィンドウに次のような出力が表示されます。
IP: Time to live = 64 seconds/hops IP: Protocol = 51 (AH) IP: Header checksum = 4e0e IP: Source address = 192.168.116.16, enigma IP: Destination address = 192.168.13.213, partym IP: No options IP: AH: ----- Authentication Header ----- AH: AH: Next header = 50 (ESP) AH: AH length = 4 (24 bytes) AH: <Reserved field = 0x0> AH: SPI = 0xb3a8d714 AH: Replay = 52 AH: ICV = c653901433ef5a7d77c76eaa AH: ESP: ----- Encapsulating Security Payload ----- ESP: ESP: SPI = 0xd4f40a61 ESP: Replay = 52 ESP: ....ENCRYPTED DATA.... ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 20 arrived at 9:44:36.59 ETHER: Packet size = 98 bytes ETHER: Destination = 8:0:27:aa:11:11, Sun ETHER: Source = 8:0:22:aa:22:2, Sun ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: .... ..0. = not ECN capable transport IP: .... ...0 = no ECN congestion experienced IP: Total length = 84 bytes IP: Identification = 40933 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 60 seconds/hops IP: Protocol = 51 (AH) IP: Header checksum = 22cc … |