| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris の管理: IP サービス Oracle Solaris 10 1/13 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris の管理: IP サービス Oracle Solaris 10 1/13 Information Library (日本語) |
1. Oracle Solaris TCP/IP プロトコル群 (概要)
5. TCP/IP ネットワークサービスと IPv4 アドレス指定の構成 (作業)
10. TCP/IP と IPv4 の詳細 (リファレンス)
17. DHCP のトラブルシューティング (リファレンス)
18. DHCP コマンドと DHCP ファイル (リファレンス)
IPsec で 2 つのシステム間のトラフィックを保護するには
IPsec を使って Web 以外のトラフィックから Web サーバーを保護する方法
Oracle Solaris System で乱数を生成する方法
IPsec セキュリティーアソシエーションを手動で作成する方法
トンネルモードを使用して VPN を IPsec で保護する例
IPsec で VPN を保護するタスクのためのネットワークトポロジの説明
IPv4 を使用するトンネルモードの IPsec トンネルで VPN を保護する方法
IPv6 を使用するトンネルモードの IPsec トンネルで VPN を保護する方法
IPv4 を使用するトランスポートモードの IPsec トンネルで VPN を保護する方法
IPv6 を使用するトランスポートモードの IPsec トンネルで VPN を保護する方法
21. IP セキュリティーアーキテクチャー (リファレンス)
25. Oracle Solaris の IP フィルタ (概要)
このセクションでは、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 プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Oracle 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 アドレスを使用しています。
# Secure communication with partym 192.168.13.213 partym 2001::eeee:3333:3333 partym
# Secure communication with enigma 192.168.116.16 enigma 2001::aaaa:6666:6666 enigma
ファイル名は /etc/inet/ipsecinit.conf です。例は、/etc/inet/ipsecinit.sample ファイルを参照してください。
{laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}{laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}IPsec ポリシーエントリの構文については、ipsecconf(1M)のマニュアルページを参照してください。
インターネットキー交換 (IKE) を構成すると、SA が自動的に生成されます。SA は手動でも追加できます。
注 - キーの生成や保守を手動で行う必要が特にない場合は、IKE を使用すべきです。IKE 鍵管理では、手動での鍵管理よりも強力なセキュリティー効果が得られます。
「IKE の構成 (タスクマップ)」の構成手順のいずれかに従って、IKE を構成します。IKE 構成ファイルの構文については、ike.config(4) のマニュアルページを参照してください。
SA を手動で追加する場合は、「IPsec セキュリティーアソシエーションを手動で作成する方法」を参照してください。
# init 6
その後、「IPsec によってパケットが保護されていることを確認する方法」に進みます。
# ipsecconf -c -f /etc/inet/ipsecinit.conf
エラーがあれば修正し、ファイルの構文を確認してから続行します。
# svcadm refresh svc:/network/ipsec/policy:default
IPsec ポリシーはデフォルトで有効になっているので、「リフレッシュ」を行います。IPsec ポリシーを無効にしてある場合は有効にしてください。
# svcadm enable svc:/network/ipsec/policy:default
# svcadm enable svc:/network/ipsec/ike:default
# svcadm restart svc:/network/ipsec/ike:default
# svcadm enable svc:/network/ipsec/manual-key:default
# svcadm refresh svc:/network/ipsec/manual-key:default
手順については、「IPsec によってパケットが保護されていることを確認する方法」を参照してください。
例 20-1 ssh 接続を使用している場合に 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 で保護されます。
例 20-2 リブートを行わないで 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 プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Oracle Solaris の管理: 基本管理』の第 2 章「Solaris 管理コンソールの操作 (タスク)」を参照してください。
注 - リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。
Web サーバーの場合、TCP ポート 80 (HTTP) と 443 (保護 HTTP) が該当します。Web サーバーが DNS 名検査をするときは、TCP と UDP の両方にポート 53 も組み込む必要がある場合もあります。
手順 12 はすべての Oracle Solaris リリースでオプションです。
/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 で説明した、検査を省略するトラフィックは例外です。
# ipsecconf -c -f /etc/inet/ipsecinit.conf
# svcadm refresh svc:/network/ipsec/policy:default
# svcadm restart svc:/network/ipsec/ike
# svcadm refresh svc:/network/ipsec/manual-key:default
これで設定が完了しました。必要に応じて、手順 12 を実行します。
注 - 次の手順は、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 で説明した、検査を省略するトラフィックは例外です。
# chmod 400 IPsecWebInitFile
次のオプションのいずれかを選択します。
鍵管理に 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 接続で使用されます。
リモートシステムの 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 コマンドを実行します。
Solaris 10 4/09 リリースより前のリリースを実行している場合、Network IPsec Management プロファイルは使用できません。Network Security プロファイルを使用してください。
ネットワークセキュリティープロファイルを含む役割を作成し、その役割をユーザーに割り当てるには、「ネットワークセキュリティーの役割を構成する方法」を参照してください。
キーを手動で指定する場合、鍵情報はランダムでなければなりません。IPsec 鍵用の鍵情報は 16 進形式です。ほかのオペレーティングシステムでは、ASCII 形式の鍵情報が必要になる場合があります。ASCII 形式を必要とするオペレーティングシステムと通信する Oracle Solaris システム用に鍵情報を生成する方法については、例 23-1 を参照してください。
乱数発生関数がすでにある場合は、それを使用してください。それ以外の場合、/dev/random デバイスを入力として od コマンドを使用できます。詳細は、od(1) のマニュアルページを参照してください。
Solaris 10 4/09 リリースでは、pktool コマンドも使用できます。このコマンドの構文は、od コマンドの構文より単純です。詳細は、『Solaris のシステム管理: セキュリティーサービス』の「pktool コマンドを使用して対称鍵を生成する方法」を参照してください。
% 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 接頭辞を使用します。
例 20-3 IPsec のキー素材の生成
次の例は、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 ゾーンのキー情報の手動管理は、大域ゾーンで行う必要があります。
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 コマンドを使用できます。手順については、「Oracle Solaris System で乱数を生成する方法」を参照してください。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Oracle Solaris の管理: 基本管理』の第 2 章「Solaris 管理コンソールの操作 (タスク)」を参照してください。
注 - リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。
# ipseckey >
> flush >
攻撃者に 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 桁の乱数が必要です。
手順 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 を使用する必要があります。
パケットを保護するには、次のコマンドを入力します。
> 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 を割り当てるべきです。
Solaris 10 4/09 リリースより前のリリースでは、この手順により、リブート時に IPsec で鍵情報を確実に使用できるようになります。
/etc/inet/secret/ipseckeys ファイルの行と ipseckey コマンド行の言語が同じになるようにします。
# 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
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
# svcadm enable svc:/network/ipsec/manual-key
現在のリリースで鍵を置き換える方法については、例 20-4 を参照してください。
例 20-4 IPsec SA を置き換える
この例では、管理者が現在の Oracle Solaris 10 リリースを実行しているシステムを構成しています。管理者は新しい鍵を生成し、ipseckeys ファイルの鍵情報を変更してから、サービスを再起動します。
まず、管理者は 「Oracle 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 出力を作成するためには、スーパーユーザーであるか、それと同等の役割でなければなりません。さらに、接続をテストするためには、両方のシステムにアクセスできなければなりません。
% su - Password: Type root password #
partym の端末ウィンドウで、enigma システムからパケットをスヌープします。
# snoop -d hme0 -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
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) でシステムを管理している場合は、ネットワーク管理またはネットワークセキュリティー上の役割を提供するためにこの手順を使用します。
現在のリリースでは、次のような出力が表示されます。
% 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 プロファイルでコマンドを実行できます。
% 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 Security または Network IPsec Management 権利プロファイルを持つ役割は、ifconfig、snoop、ipsecconf、および ipseckey コマンドなどを適切な特権で実行できます。
役割の作成、役割のユーザーへの割り当て、ネームサービスによる変更点の登録については、『Solaris のシステム管理: セキュリティーサービス』の「RBAC の構成 (タスクマップ)」を参照してください。
例 20-5 ネットワークセキュリティーの責任を役割に振り分ける
この例では、管理者がネットワークセキュリティーの責任を 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 サービスは無効になっています。
# svcadm refresh svc:/network/ipsec/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
# svcadm enable svc:/network/ipsec/ike
# svcadm restart 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
# svcadm disable svc:/network/ipsec/ike
# svcadm enable svc:/network/ipsec/manual-key
# 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
# svcadm disable svc:/network/ipsec/manual-key
# svcadm refresh svc:/network/ipsec/ipsecalgs
注意事項
サービスのステータスを調べるには、svcs service コマンドを使用します。サービスが maintenance (保守) モードになっている場合は、svcs -x service コマンドの出力に表示されるデバッグのヒントに従ってください。
|