この節では、2 つのシステム間のトラフィックを保護する手順と、Web サーバーを保護する手順について説明します。VPN を保護する手順については、「IPsec による VPN の保護 (作業マップ) 」を参照してください。追加手順では、鍵情報とセキュリティーアソシエーションの提供、IPsec が設定どおり動作しているかどうかの確認を行います。
次の情報は、すべての IPsec 構成作業で使用されます。
IPsec とゾーン – 共有 IP 非大域ゾーンの IPsec ポリシーとキーを管理するには、大域ゾーンで IPsec ポリシーファイルを作成し、大域ゾーンで IPsec 構成コマンドを実行します。構成中の非大域ゾーンに対応する発信元アドレスを使用してください。大域ゾーンでは、大域ゾーンの IPsec ポリシーとキーも設定できます。排他的 IP ゾーンについては、非大域ゾーンで IPsec ポリシーを構成します。Solaris 10 7/07 リリース以降では、非大域ゾーンのキーの管理に IKE を使用できます。
IPsec と RBAC – IPsec を管理する役割を使用する方法については、『Solaris のシステム管理 (セキュリティサービス)』の第 9 章「役割によるアクセス制御の使用 (手順)」を参照してください。例については、「ネットワークセキュリティーの役割を設定する方法」を参照してください。
IPsec と SCTP – IPsec は、Streams Control Transmission Protocol (SCTP) アソシエーションを保護するのに使用できますが、注意が必要です。詳細は、「IPsec と SCTP」を参照してください。
この手順では、次の設定がすでになされているものとします。
2 つのシステムが enigma および partym と名付けられている。
各システムには、2 つのアドレス (IPv4 アドレスと IPv6 アドレス) がある。
各システムには、AES アルゴリズムを使用した ESP 暗号化 (128 ビットのキーが必要) と、SHA1 メッセージ要約を使用した ESP 認証 (160 ビットのキーが必要) が必要です。
各システムは、共有セキュリティーアソシエーションを使用します。
共有セキュリティーアソシエーションでは、2 つのシステムを保護するのに必要なのは 1 組だけの SA です。
システムまたは共有 IP ゾーンの IPsec ポリシーの構成は、大域ゾーンで行う必要があります。排他的 IP ゾーンについては、非大域ゾーンで IPsec ポリシーを構成します。
システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される可能性があります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。例については、例 20–1 を参照してください。
現在のリリースでは、/etc/inet/hosts ファイルにホストエントリを追加します。
Solaris 10 7/07 リリースより前のリリースを実行しているシステムでは、/etc/inet/ipnodes ファイルに IPv4 と IPv6 のエントリを追加します。次のように、1 つのシステムのエントリは連続してそのファイルに入力します。システムの構成ファイルについては、「TCP/IP 構成ファイル」および第 11 章IPv6 の詳細 (リファレンス)を参照してください。
IPv4 アドレスだけを持つシステムどうしを接続する場合は、/etc/inet/hosts ファイルに変更を加えます。この例で接続するシステムはどちらも、以前の Solaris リリースを実行しており、IPv6 アドレスを使用しています。
ファイル名は /etc/inet/ipsecinit.conf です。例は、/etc/inet/ipsecinit.sample ファイルを参照してください。
IPsec ポリシーエントリを ipsecinit.conf ファイルに追加します。
enigma システムで、次のポリシーを追加します。
{laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
partym システムで、同じポリシーを追加します。
{laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
IPsec ポリシーエントリの構文については、ipsecconf(1M)のマニュアルページを参照してください。
各システムで、2 つのシステム間に IPsec SA ペアを追加します。
インターネットキー交換 (IKE) を設定すると、SA が自動的に生成されます。SA は手動でも追加できます。
キーの生成や保守を手動で行う必要が特にない場合は、IKE を使用すべきです。IKE 鍵管理では、手動での鍵管理よりも強力なセキュリティー効果が得られます。
「IKE の設定 (作業マップ)」の構成手順のいずれかに従って、IKE を構成します。IKE 構成ファイルの構文については、ike.config(4) のマニュアルページを参照してください。
SA を手動で追加する場合は、「IPsec セキュリティーアソシエーションを手動で作成する方法」を参照してください。
IPsec ポリシーを有効にします。
Solaris 10 4/09 リリースより前のリリースを実行している場合は、システムを再起動します。
# init 6 |
その後、「IPsec によってパケットが保護されていることを確認する方法」に進みます。
Solaris 10 4/09 リリース以降では、IPsec サービスを更新し、鍵管理サービスを有効にします。
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
エラーがあれば修正し、ファイルの構文を確認してから続行します。
# svcadm refresh svc:/network/ipsec/policy:default |
IPsec ポリシーはデフォルトで有効になっているので、「更新」を行います。IPsec ポリシーを無効にしてある場合は有効にしてください。
# svcadm enable svc:/network/ipsec/policy:default |
IPsec 用の鍵を有効にします。
パケットが保護されていることを確認します。
手順については、「IPsec によってパケットが保護されていることを確認する方法」を参照してください。
この例では、管理者はスーパーユーザーとして 2 つのシステムの IPsec ポリシーと鍵を構成します。その際、ssh コマンドを使用して 2 番目のシステムにアクセスします。詳細は、ssh(1) のマニュアルページを参照してください。
次に、別の端末ウィンドウで、ssh コマンドを使用して 2 番目のシステムにログインします。
local-system # ssh other-system other-system # |
ssh セッションの端末ウィンドウで、手順 2 から 手順 6 までを実行して、2 番目のシステムの IPsec ポリシーと鍵を構成します。
ここで ssh セッションを終了します。
other-system # exit local-system # |
最後に、手順 6 を実行して、最初のシステムの IPsec ポリシーを有効にします。
2 つのシステムが次に通信を行うとき、ssh 接続を使用した通信も含め、通信は IPsec で保護されます。
次の例は、Solaris 10 4/09 リリースより前のリリースを実行している場合に役立ちます。つまり、そのようなリリースでは、IPsec はサービスとして管理されません。この例では、テスト環境での IPsec の実装方法を示します。実際の稼働環境では、ipsecconf コマンドを実行するよりもリブートする方が安全です。セキュリティー上の考慮事項については、この例の最後を参照してください。
手順 6 でリブートする代わりに、次のオプションのいずれかを選択します。
IKE を使って鍵情報を作成した場合は、in.iked デーモンをいったん停止後、再起動します。
# pkill in.iked # /usr/lib/inet/in.iked |
キーを手動で追加した場合は、ipseckey コマンドを使用して、データベースに SA を追加します。
# ipseckey -c -f /etc/inet/secret/ipseckeys |
続いて、ipsecconf コマンドを使用して IPsec ポリシーを有効にします。
# ipsecconf -a /etc/inet/ipsecinit.conf |
セキュリティーについて – ipsecconf コマンドを実行するときには、警告を読んでください。ソケットがすでにラッチされている (使用されている) 場合には、システムへ侵入される恐れがあります。詳細については、「ipsecinit.conf と ipsecconf のセキュリティーについて」を参照してください。
セキュリティー保護された Web サーバーでは、Web クライアントであれば Web サービスと通信できます。セキュリティー保護された Web サーバーでは、Web トラフィック以外のトラフィックは、セキュリティー検査を通る必要があります。次の手順には、Web トラフィックの検査省略手順が含まれています。さらに、この Web サーバーでは、セキュリティー保護されていない DNS クライアント要求を出すことができます。その他のすべてのトラフィックでは、AES と SHA-1 アルゴリズムによる ESP が必要です。
IPsec ポリシーの構成は大域ゾーンで行う必要があります。排他的 IP ゾーンについては、非大域ゾーンで IPsec ポリシーを構成します。「IPsec で 2 つのシステム間のトラフィックを保護するには」を完了して、次の条件が成立しています。
2 つのシステム間の通信は IPsec で保護されています。
鍵情報は手動または IKE によって生成されます。
パケットが保護されていることを確認してあります。
システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。
セキュリティーポリシー検査を省略するサービスを指定します。
Web サーバーの場合、TCP ポート 80 (HTTP) と 443 (保護 HTTP) が該当します。Web サーバーが DNS 名検査をするときは、TCP と UDP の両方にポート 53 も組み込む必要がある場合もあります。
Web サーバーの IPsec ポリシーを作成し、有効にします。
手順 12 はすべての Solaris リリースで省略可能です。
Web サーバーのポリシーを IPsec ポリシーファイルに追加します。
/etc/inet/ipsecinit.conf ファイルに次の行を追加します。
# Web traffic that web server should bypass. {lport 80 ulp tcp dir both} bypass {} {lport 443 ulp tcp dir both} bypass {} # Outbound DNS lookups should also be bypassed. {rport 53 dir both} bypass {} # Require all other traffic to use ESP with AES and SHA-1. # Use a unique SA for outbound traffic from the port {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
これで、保護トラフィックだけがシステムへのアクセスを許可されます。ただし、手順 4 で説明した、検査を省略するトラフィックは例外です。
IPsec ポリシーファイルの構文を確認します。
# ipsecconf -c -f /etc/inet/ipsecinit.conf |
IPsec ポリシーを更新します。
# svcadm refresh svc:/network/ipsec/policy:default |
IPsec 用の鍵を更新します。
「IPsec で 2 つのシステム間のトラフィックを保護するには」の手順 5 で IKE を構成した場合は、ike サービスを再起動します。
# svcadm restart svc:/network/ipsec/ike |
「IPsec で 2 つのシステム間のトラフィックを保護するには」の手順 5 で鍵を手動で構成した場合は、manual-key サービスを更新します。
# svcadm refresh svc:/network/ipsec/manual-key:default |
これで設定が完了しました。必要に応じて、手順 12 を実行します。
Web サーバーポリシー用のファイルを /etc/inet ディレクトリに 作成します。
次の手順は、Solaris 10 4/09 リリースより前のリリースを実行している Web サーバーを構成するためのものです。
このファイルにその目的を表す名前を与えます (たとえば、IPsecWebInitFile)。このファイルに次のように入力します。
# Web traffic that web server should bypass. {lport 80 ulp tcp dir both} bypass {} {lport 443 ulp tcp dir both} bypass {} # Outbound DNS lookups should also be bypassed. {rport 53 dir both} bypass {} # Require all other traffic to use ESP with AES and SHA-1. # Use a unique SA for outbound traffic from the port {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
これで、保護トラフィックだけがシステムへのアクセスを許可されます。ただし、手順 4 で説明した、検査を省略するトラフィックは例外です。
手順 8 で作成したファイルの内容を /etc/inet/ipsecinit.conf ファイルにコピーします。
IPsecWebInitFile ファイルを読み取り専用アクセス権で保護します。
# chmod 400 IPsecWebInitFile |
リブートせずに Web サーバーをセキュリティー保護します。
次のオプションのいずれかを選択します。
鍵管理に IKE を使用する場合は、in.iked デーモンをいったん停止後、再起動します。
# pkill in.iked # /usr/lib/inet/in.iked |
手動でキーを管理する場合は、ipseckey および ipsecconf コマンドを実行します。
ipsecconf コマンドの引数には、 IPsecWebInitFile を使用します。引数に ipsecinit.conf ファイルを使用すると、ipsecconf コマンドは、ファイル内のポリシーがすでにシステムに実装されている場合は、エラーを生成します。
# ipseckey -c -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/IPsecWebInitFile |
ipsecconf コマンドの実行時には警告を読んでください。ソケットがすでにラッチされている (使用されている) 場合には、システムへ侵入される恐れがあります。詳細については、「ipsecinit.conf と ipsecconf のセキュリティーについて」を参照してください。in.iked デーモンの再起動時にも、同じ警告が表示されます。
リブートすることもできます。システムをリブートすると、IPsec ポリシーがすべての TCP 接続に適用されます。リブート時に、IPsec ポリシーのファイルで指定したポリシーが TCP 接続で使用されます。
(省略可能) Web 以外のトラフィックのために Web サーバーと通信する場合は、リモートシステムを有効にします。
リモートシステムの ipsecinit.conf ファイルに次のポリシーを入力します。
# Communicate with web server about nonweb stuff # {laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared} |
IPsec ポリシーが一致した場合にかぎり、リモートシステムは、非 Web トラフィックを持つ Web サーバーと安全に通信できます。
引数を指定しないで ipsecconf コマンドを実行すると、システムに構成されているポリシーを確認できます。
ipsecconf コマンドは大域ゾーンで実行する必要があります。排他的 IP ゾーンについては、非大域ゾーンで ipsecconf コマンドを実行します。
Network IPsec Management プロファイルを持つ役割またはスーパーユーザーになります。
Solaris 10 4/09 リリースより前のリリースを実行している場合、Network IPsec Management プロファイルは使用できません。Network Security プロファイルを使用してください。
ネットワークセキュリティープロファイルを含む役割を作成し、その役割をユーザーに割り当てるには、「ネットワークセキュリティーの役割を設定する方法」を参照してください。
IPsec ポリシーの表示
キーを手動で指定する場合、鍵情報はランダムでなければなりません。Solaris システム用の鍵情報は 16 進形式です。ほかのオペレーティングシステムでは、ASCII 形式の鍵情報が必要になる場合があります。ASCII 形式を必要とするオペレーティングシステムと通信する Solaris システム用に鍵情報を生成する方法については、例 23–1 を参照してください。
乱数発生関数がすでにある場合は、それを使用してください。ない場合は、Solaris の /dev/random デバイスを入力として od コマンドを実行できます。詳細は、od(1) のマニュアルページを参照してください。
Solaris 10 4/09 リリースでは、pktool コマンドも使用できます。このコマンドの構文は、od コマンドの構文より単純です。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「pktool コマンドを使用して対称鍵を生成する方法」を参照してください。
16 進数の乱数を生成します。
% od -x|-X -A n file | head -n |
8 進数ダンプを 16 進数形式で表示します。16 進数形式は鍵情報を表すのに役立ちます。16 進数を 4 文字単位で表示します。
8 進数ダンプを 16 進数形式で表示します。16 進数を 8 文字単位で表示します。
表示から入力オフセットベースを取り除きます。
乱数のソースとなります。
出力の冒頭の n 行に表示を限定します。
これらの出力を組み合わせて、適切な長さのキーを作成します。
同じ行にある乱数間のスペースを取り除き、32 文字キーを作成します。32 文字キーの長さは 128 ビットです。セキュリティーパラメータインデックス (SPI) の場合は、8 文字キー 1 個を使用します。そのキーは、0x 接頭辞を使用します。
次の例は、8 つ 16 進数文字のグループそれぞれに 2 行のキーを表示します。
% od -X -A n /dev/random | head -2 d54d1536 4a3e0352 0faf93bd 24fd6cad 8ecc2670 f3447465 20db0b0c c83f5a4b |
最初の行で 4 つの数字を組み合わせることで、32 文字のキーを作成できます。0x に続く 8 文字の数字は、0xf3447465 などの適切な SPI 値を提供します。
次の例は、4 つ 16 進数文字のグループそれぞれに 2 行のキーを表示します。
% od -x -A n /dev/random | head -2 34ce 56b2 8b1b 3677 9231 42e9 80b0 c673 2f74 2817 8026 df68 12f4 905a db3d ef27 |
最初の行で 4 つの数字を組み合わせることで、32 文字のキーを作成できます。
次の手順では、「IPsec で 2 つのシステム間のトラフィックを保護するには」の手順で使用するキー作成素材を提供します。partym と enigma という 2 つのシステムの鍵を生成しようとしています。一方のシステムで鍵を生成してから、このシステムの鍵を両方のシステムで使用します。
共有 IP ゾーンのキー情報の手動管理は、大域ゾーンで行う必要があります。
SA の鍵情報を生成します。
16 進のアウトバウンドトラフィックと、同じく 16 進のインバウンドトラフィックには、それぞれ 3 種類の乱数が必要です。
つまり、1 台のシステムで次の数値を生成する必要があります。
spi キーワードの値として、2 つの 16 進数の乱数。1 つはアウトバウンドトラフィック用です。もう 1 つはインバウンドトラフィック用です。それぞれの乱数の最大桁数は 8 桁です。
認証の SHA1 アルゴリズム用として、2 つの 16 進数の乱数。160 ビットのキーの場合、各乱数は 40 桁でなければなりません。1 つは dst enigma 用です。もう 1 つは dst partym 用です。
ESP 暗号化の AES アルゴリズム用として、2 つの 16 進数の乱数。256 ビットのキーの場合、各乱数は 64 桁でなければなりません。1 つは dst enigma 用です。もう 1 つは dst partym 用です。
乱数発生関数がすでにある場合は、それを使用してください。ない場合は、od コマンドを使用できます。手順については、「Solaris System で乱数を生成するには」を参照してください。
いずれかのシステムのシステムコンソールで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。
SA を作成します。
次のコマンドを入力して ipseckey コマンドモードを有効にします。
# ipseckey > |
既存の SA を置き換える場合は、現在の SA を消去してください。
> flush > |
攻撃者に SA を破る時間を与えないように、キー作成素材は置き換えが必要です。
管理者は、通信システム上のキーの置き換えを調整する必要があります。あるシステムの SA を置き換える場合は、それと通信しているリモートシステムの SA も置き換える必要があります。
SA を作成するには、次のコマンドを実行します。
> add protocol spi random-hex-string \ src addr dst addr2 \ protocol-prefix_alg protocol-algorithm \ protocol-prefixkey random-hex-string-of-algorithm-specified-length |
次の構文で、フラッシュした SA を置き換えることもできます。
esp または ah を指定します。
16 進数形式の最大 8 桁の乱数を指定します。0x が前置されます。セキュリティーパラメータインデックス (SPI) が受け取る以上の桁数を入力すると、超過部分は無視されます。SPI が受け取るより少ない桁数を入力すると、パディングが行われます。
システムの IP アドレスを指定します。
addr のピアシステムの IP アドレスを指定します。
encr または auth を指定します。encr 接頭辞は esp プロトコルとともに使用されます。auth 接頭辞は ah プロトコルとともに、そして、esp プロトコルを認証する場合に使用されます。
ESP または AH のアルゴリズムを指定します。それぞれのアルゴリズムには、特定の長さのキーが必要です。
認証アルゴリズムには MD5 と SHA1 があります。Solaris 10 4/09 リリース以降では、SHA256 と SHA512 がサポートされています。暗号化アルゴリズムには、DES、3DES、AES、および Blowfish があります。
アルゴリズムによって必要とされる長さをもつ 16 進数の乱数を指定します。たとえば、MD5 アルゴリズムでは、128 ビットキーのため 32 桁の乱数が必要です。3DES アルゴリズムでは、192 ビットキーのため 48 桁の乱数が必要です。
たとえば、enigma システムで出力パケットを保護します。
手順 1 で生成した乱数を使用します。
Solaris 10 1/06 の場合:
> add esp spi 0x8bcd1407 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \ authkey 6fab07fec4f2895445500ed992ab48835b9286ff > |
ピアシステムでは、同じ鍵情報および同じ SPI を使用する必要があります。
enigma システムの ipseckey コマンドモードでは、入力パケットを保護します。
パケットを保護するには、次のコマンドを入力します。
> add esp spi 0x122a43e4 \ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \ authkey c80984bc4733cc0b7c228b9b74b988d2b7467745 > |
これらのキーと SPI は、SA ごとに変更できます。SA ごとに異なるキーと異なる SPI を割り当てるべきです。
ipseckey コマンドモードを終了するには、Control-D キーを押すか、quit と入力します。
/etc/inet/secret/ipseckeys ファイルに鍵情報を追加します。
Solaris 10 4/09 リリースより前のリリースでは、この手順により、リブート時に IPsec で鍵情報を確実に使用できるようになります。
/etc/inet/secret/ipseckeys ファイルの行と ipseckey コマンド行の言語が同じになるようにします。
たとえば、enigma システム上の /etc/inet/secret/ipseckeys ファイルは次のようになります。
# ipseckeys - This file takes the file format documented in # ipseckey(1m). # Note that naming services might not be available when this file # loads, just like ipsecinit.conf. # # for outbound packets on enigma add esp spi 0x8bcd1407 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \ authkey 6fab07fec4f2895445500ed992ab48835b9286ff # # for inbound packets add esp spi 0x122a43e4 \ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \ authkey c80984bc4733cc0b7c228b9b74b988d2b7467745 |
# chmod 400 /etc/inet/secret/ipseckeys |
partym システムでこの手順を繰り返します。
enigma システムの場合と同じ鍵情報を使用します。
両システムの鍵情報は同じでなければなりません。次の例のように、ipseckeys ファイル内のコメントだけが異なります。コメントが異なるのは、dst enigma が enigma システム上ではインバウンド、partym システム上ではアウトバウンドになるからです。
# partym ipseckeys file # # for inbound packets add esp spi 0x8bcd1407 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \ authkey 6fab07fec4f2895445500ed992ab48835b9286ff # # for outbound packets add esp spi 0x122a43e4 \ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \ authkey c80984bc4733cc0b7c228b9b74b988d2b7467745 |
manual-key サービスを有効にします。
# svcadm enable svc:/network/ipsec/manual-key |
現在のリリースで鍵を置き換える方法については、例 20–4 を参照してください。
この例では、管理者が現在の Solaris 10 リリースを実行しているシステムを構成しようとしています。管理者は新しい鍵を生成し、ipseckeys ファイルの鍵情報を変更してから、サービスを再起動します。
まず、管理者は 「Solaris System で乱数を生成するには」を実行して鍵を生成します。
次に、生成された鍵を /etc/inet/secret/ipseckeys ファイルで使用します。
管理者は同じアルゴリズムを使用しました。そのため、SPI、encrkey、および authkey の値だけを変更します。
add esp spi 0x8xzy1492 \ src 192.168.116.16 dst 192.168.13.213 \ encr_alg aes \ auth_alg sha1 \ encrkey 0a1f3886b06ebd7d39f6f89e4c29c93f2741c6fa598a38af969907a29ab1b42a \ authkey a7230aabf513f35785da73e33b064608be41f69a # # add esp spi 0x177xce34\ src 192.168.13.213 dst 192.168.116.16 \ encr_alg aes \ auth_alg sha1 \ encrkey 4ef5be40bf93498017b2151d788bb37e372f091add9b11149fba42435fefe328 \ authkey 0e1875d9ff8e42ab652766a5cad49f38c9152821 |
最後に、管理者は manual-key サービスを再起動します。restart コマンドにより、新しい鍵を追加する前に古い鍵が消去されます
# svcadm restart manual-key |
パケットが保護されていることを確認するには、snoop コマンドで接続をテストします。snoop 出力に表示される接頭辞は、次のとおりです。
AH: 接頭辞は、AH がヘッダーを保護していることを示します。AH: が表示されるのは、auth_alg を使ってトラフィックを保護している場合です。
ESP: 接頭辞は、暗号化されたデータが送信されていることを示します。ESP: が表示されるのは、encr_auth_alg か encr_alg を使ってトラフィックを保護している場合です。
snoop 出力を作成するためには、スーパーユーザーであるか、それと同等の役割でなければなりません。さらに、接続をテストするためには、両方のシステムにアクセスできなければなりません。
一方のシステム (たとえば、partym) でスーパーユーザー になります。
% su - Password: Type root password # |
partym システムから、リモートシステムからパケットをスヌープする準備をします。
partym の端末ウィンドウで、enigma システムからパケットをスヌープします。
# snoop -v enigma Using device /dev/hme (promiscuous mode) |
リモートシステムからパケットを送信します。
別の端末ウィンドウで、enigma システムにリモートからログインします。パスワードを入力します。次に、スーパーユーザーになり、enigma システムからのパケットを partym システムに送信します。パケットは、snoop -v enigma コマンドで取り込む必要があります。
% ssh enigma Password: Type your password % su - Password: Type root password # ping partym |
snoop の出力を調べます。
partym システムで、冒頭の IP ヘッダー情報のあとに AH と ESP 情報が含まれている出力を確認します。次のような AH と ESP の情報は、パケットが保護されていることを示します。
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 ----- ... |
役割によるアクセス制御 (RBAC) でシステムを管理している場合は、ネットワーク管理またはネットワークセキュリティー上の役割を提供するためにこの手順を使用します。
ローカルの prof_attr データベースで Network 権利プロファイルを検索します。
現在のリリースでは、次のような出力が表示されます。
% cd /etc/security % grep Network prof_attr Network IPsec Management:::Manage IPsec and IKE... Network Link Security:::Manage network link security... Network Management:::Manage the host and network configuration... Network Security:::Manage network and host security... Network Wifi Management:::Manage wifi network configuration... Network Wifi Security:::Manage wifi network security... |
Solaris 10 4/09 リリースより前のリリースを実行している場合は、次のような出力が表示されます。
% cd /etc/security % grep Network prof_attr Network Management:::Manage the host and network configuration Network Security:::Manage network and host security System Administrator::: Network Management |
Network Management プロファイルは、System Administrator プロファイルを補完するプロファイルです。System Administrator 権利プロファイルを役割に含めると、その役割は Network Management プロファイルでコマンドを実行できます。
Network Management 権利プロファイルに含まれているコマンドを調べます。
% grep "Network Management" /etc/security/exec_attr Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config … Network Management:suser:cmd:::/usr/sbin/snoop:uid=0 |
solaris ポリシーコマンドは、特権 (privs=sys_net_config) で実行されます。suser ポリシーコマンドは、スーパーユーザー (uid=0) として実行されます。
サイトでのネットワークセキュリティーの役割の範囲を決定します。
決定には、手順 1 の権利プロファイルの定義を参考にしてください。
Network Management 権利プロファイルを含むネットワークセキュリティーの役割を作成します。
Network Management プロファイルに加え、Network Security または Network IPsec Management 権利プロファイルを持つ役割は、ifconfig、snoop、ipsecconf、および ipseckey コマンドなどを適切な特権で実行できます。
役割の作成、役割のユーザーへの割り当て、ネームサービスによる変更点の登録については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。
この例では、管理者がネットワークセキュリティーの責任を 2 つの役割に振り分けます。一方の役割は wifi とリンクのセキュリティーを管理し、もう一方の役割は IPsec と IKE を管理します。各役割には、シフトごとに 1 人、合計 3 人を割り当てます。
管理者によって次のように役割が作成されます。
最初の役割には LinkWifi という名前を付けます。
この役割には Network Wifi、Network Link Security、および Network Management 権利プロファイルを割り当てます。
その後、該当するユーザーにこの LinkWifi 役割を割り当てます。
2 番目の役割には IPsec Administrator という名前を付けます。
この役割には Network IPsec Management および Network Management 権利プロファイルを割り当てます。
その後、該当するユーザーにこの IPsec Administrator 役割を割り当てます。
次の手順では、IPsec の管理、IKE の管理、および手動での鍵管理に SMF サービスを使用する代表的な方法について説明します。デフォルトでは、policy サービスと ipsecalgs サービスは有効になっています。また、デフォルトでは、ike サービスと manual-key サービスは無効になっています。
IPsec ポリシーを管理するには、次のいずれかを実行します。
ipsecinit.conf ファイルに新しいポリシーを追加したあと、policy サービスを更新します。
# svcadm refresh svc:/network/ipsec/policy |
サービスのプロパティーの値を変更したあと、プロパティーの値を表示し、policy サービスを更新してから再起動します。
# svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf # svcprop -p config/config_file policy /etc/inet/MyIpsecinit.conf # svcadm refresh svc:/network/ipsec/policy # svcadm restart svc:/network/ipsec/policy |
鍵を自動的に管理するには、次のいずれかを実行します。
/etc/inet/ike/config ファイルにエントリを追加したあと、ike サービスを有効にします。
# svcadm enable svc:/network/ipsec/ike |
/etc/inet/ike/config ファイルのエントリを変更したあと、ike サービスを更新します。
# svcadm refresh svc:/network/ipsec/ike |
サービスのプロパティーの値を変更したあと、プロパティーの値を表示し、サービスを更新してから再起動します。
# svccfg -s ike setprop config/admin_privilege=modkeys # svcprop -p config/admin_privilege ike modkeys # svcadm refresh svc:/network/ipsec/ike # svcadm restart svc:/network/ipsec/ike |
ike サービスを停止するには、無効にします。
# svcadm disable svc:/network/ipsec/ike |
鍵を手動で管理するには、次のいずれかを実行します。
/etc/inet/secret/ipseckeys ファイルにエントリを追加したあと、manual-key サービスを有効にします。
# svcadm enable svc:/network/ipsec/manual-key |
ipseckeys ファイルを変更したあと、サービスを更新します。
# svcadm refresh manual-key |
サービスのプロパティーの値を変更したあと、プロパティーの値を表示し、サービスを更新してから再起動します。
# svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile # svcprop -p config/config_file manual-key /etc/inet/secret/MyIpseckeyfile # svcadm refresh svc:/network/ipsec/manual-key # svcadm restart svc:/network/ipsec/manual-key |
鍵を手動で管理できないようにするには、manual-key サービスを無効にします。
# svcadm disable svc:/network/ipsec/manual-key |
IPsec のプロトコルとアルゴリズムのテーブルを変更した場合は、ipsecalgs サービスを更新します。
# svcadm refresh svc:/network/ipsec/ipsecalgs |
サービスの状態を調べるには、svcs service コマンドを使用します。サービスが maintenance (保守) モードになっている場合は、svcs -x service コマンドの出力に表示されるデバッグのヒントに従ってください。