Part I Introducing System Administration: IP Services
1. Oracle Solaris TCP/IP Protocol Suite (Overview)
2. Planning Your TCP/IP Network (Tasks)
3. Introducing IPv6 (Overview)
4. Planning an IPv6 Network (Tasks)
5. Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)
6. Administering Network Interfaces (Tasks)
7. Configuring an IPv6 Network (Tasks)
8. Administering a TCP/IP Network (Tasks)
9. Troubleshooting Network Problems (Tasks)
10. TCP/IP and IPv4 in Depth (Reference)
13. Planning for DHCP Service (Tasks)
14. Configuring the DHCP Service (Tasks)
15. Administering DHCP (Tasks)
16. Configuring and Administering the DHCP Client
17. Troubleshooting DHCP (Reference)
18. DHCP Commands and Files (Reference)
19. IP Security Architecture (Overview)
Protecting Traffic With IPsec (Task Map)
How to Secure Traffic Between Two Systems With IPsec
How to Use IPsec to Protect a Web Server From Nonweb Traffic
How to Generate Random Numbers on a Solaris System
How to Manually Create IPsec Security Associations
How to Verify That Packets Are Protected With IPsec
Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode
Protecting a VPN With IPsec (Task Map)
Description of the Network Topology for the IPsec Tasks to Protect a VPN
How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4
How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6
How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4
How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6
21. IP Security Architecture (Reference)
22. Internet Key Exchange (Overview)
24. Internet Key Exchange (Reference)
25. IP Filter in Oracle Solaris (Overview)
28. Administering Mobile IP (Tasks)
29. Mobile IP Files and Commands (Reference)
30. Introducing IPMP (Overview)
31. Administering IPMP (Tasks)
Part VII IP Quality of Service (IPQoS)
32. Introducing IPQoS (Overview)
33. Planning for an IPQoS-Enabled Network (Tasks)
34. Creating the IPQoS Configuration File (Tasks)
35. Starting and Maintaining IPQoS (Tasks)
36. Using Flow Accounting and Statistics Gathering (Tasks)
This section provides procedures that enable you to secure traffic between two systems and to secure a web server. To protect a VPN, see Protecting a VPN With IPsec (Task Map) . Additional procedures provide keying material and security associations, and verify that IPsec is working as configured.
The following information applies to all IPsec configuration tasks:
IPsec and zones – To manage IPsec policy and keys for a shared-IP non-global zone, create the IPsec policy file in the global zone, and run the IPsec configuration commands from the global zone. Use the source address that corresponds to the non-global zone that is being configured. You can also configure IPsec policy and keys in the global zone for the global zone. For an exclusive-IP zone, you configure IPsec policy in the non-global zone. Starting in the Solaris 10 7/07 release, you can use IKE to manage keys in a non-global zone.
IPsec and RBAC – To use roles to administer IPsec, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. For an example, see How to Configure a Role for Network Security.
IPsec and SCTP – IPsec can be used to protect Streams Control Transmission Protocol (SCTP) associations, but caution must be used. For more information, see IPsec and SCTP.
This procedure assumes the following setup:
The two systems are named enigma and partym.
Each system has two addresses, an IPv4 address and an IPv6 address.
Each system requires ESP encryption with the AES algorithm, which requires a key of 128 bits, and ESP authentication with the SHA1 message digest, which requires a 160–bit key.
Each system uses shared security associations.
With shared SAs, only one pair of SAs is needed to protect the two systems.
You must be in the global zone to configure IPsec policy for the system or for a shared-IP zone. For an exclusive-IP zone, you configure IPsec policy in the non-global zone.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login. For an example, see Example 20-1.
In the current release, add the host entries to the /etc/inet/hosts file.
On a system that is running a release prior to the Solaris 10 7/07 release, add IPv4 and IPv6 entries to the /etc/inet/ipnodes file. The entries for one system must be contiguous in the file. For more information about system configuration files, see TCP/IP Configuration Files and Chapter 11, IPv6 in Depth (Reference).
If you are connecting systems with IPv4 addresses only, you modify the /etc/inet/hosts file. In this example, the connecting systems are running an earlier Solaris release and are using IPv6 addresses.
# 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
The file name is /etc/inet/ipsecinit.conf. For an example, see the /etc/inet/ipsecinit.sample file.
{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}
For the syntax of IPsec policy entries, see the ipsecconf(1M) man page.
You can configure Internet Key Exchange (IKE) to create the SAs automatically. You can also add the SAs manually.
Note - You should use IKE unless you have good reason to generate and maintain your keys manually. IKE key management is more secure than manual key management.
Configure IKE by following one of the configuration procedures in Configuring IKE (Task Map). For the syntax of the IKE configuration file, see the ike.config(4) man page.
To add the SAs manually, see How to Manually Create IPsec Security Associations.
# init 6
Then, go to How to Verify That Packets Are Protected With IPsec.
# ipsecconf -c -f /etc/inet/ipsecinit.conf
Fix any errors, verify the syntax of the file, and continue.
# svcadm refresh svc:/network/ipsec/policy:default
IPsec policy is enabled by default, so you refresh it. If you have disabled IPsec policy, enable it.
# 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
For the procedure, see How to Verify That Packets Are Protected With IPsec.
Example 20-1 Adding IPsec Policy When Using an ssh Connection
In this example, the administrator as superuser configures IPsec policy and keys on two systems by using the ssh command to reach the second system. For more information, see the ssh(1) man page.
First, the administrator configures the first system by performing Step 2 through Step 5 of the preceding procedure.
Then, in a different terminal window, the administrator uses the ssh command to log in to the second system.
local-system # ssh other-system other-system #
In the terminal window of the ssh session, the administrator configures the IPsec policy and keys of the second system by completing Step 2 through Step 6.
Then, the administrator ends the ssh session.
other-system # exit local-system #
Finally, the administrator enables IPsec policy on the first system by completing Step 6.
The next time the two systems communicate, including by using an ssh connection, the communication is protected by IPsec.
Example 20-2 Securing Traffic With IPsec Without Rebooting
The following example is useful when you are running a release prior to the Solaris 10 4/09 release. That is, in your release, IPsec is not managed as a service. The example describes how to implement IPsec in a test environment. In a production environment, it is more secure to reboot than to run the ipsecconf command. For the security considerations, see the end of this example.
Instead of rebooting at Step 6, choose one of the following options:
If you used IKE to create keying material, stop and then restart the in.iked daemon.
# pkill in.iked # /usr/lib/inet/in.iked
If you added keys manually, use the ipseckey command to add the SAs to the database.
# ipseckey -c -f /etc/inet/secret/ipseckeys
Then, activate the IPsec policy with the ipsecconf command.
# ipsecconf -a /etc/inet/ipsecinit.conf
Security Considerations – Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, a socket that is already in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf.
A secure web server allows web clients to talk to the web service. On a secure web server, traffic that is not web traffic must pass security checks. The following procedure includes bypasses for web traffic. In addition, this web server can make unsecured DNS client requests. All other traffic requires ESP with AES and SHA-1 algorithms.
You must be in the global zone to configure IPsec policy. For an exclusive-IP zone, you configure IPsec policy in the non-global zone. You have completed How to Secure Traffic Between Two Systems With IPsec so that the following conditions are in effect:
Communication between the two systems is protected by IPsec.
Keying material is being generated, either manually or by IKE.
You have verified that packets are being protected.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.
For a web server, these services include TCP ports 80 (HTTP) and 443 (Secure HTTP). If the web server provides DNS name lookups, the server might also need to include port 53 for both TCP and UDP.
Step 12 is optional in all Solaris releases.
Add the following lines to the /etc/inet/ipsecinit.conf file:
# 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}
This configuration allows only secure traffic to access the system, with the bypass exceptions that are described in Step 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
Your setup is complete. Optionally, you can perform Step 12.
Note - The following steps configure a web server that is running a release prior to the Solaris 10 4/09 release.
Give the file a name that indicates its purpose, for example IPsecWebInitFile. Type the following lines in this file:
# 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}
This configuration allows only secure traffic to access the system, with the bypass exceptions that are described in Step 4.
# chmod 400 IPsecWebInitFile
Choose one of the following options:
If you are using IKE for key management, stop and restart the in.iked daemon.
# pkill in.iked # /usr/lib/inet/in.iked
If you are manually managing keys, use the ipseckey and ipsecconf commands.
Use the IPsecWebInitFile as the argument to the ipsecconf command. If you use the ipsecinit.conf file as the argument, the ipsecconf command generates errors when policies in the file are already implemented on the system.
# ipseckey -c -f /etc/inet/secret/ipseckeys # ipsecconf -a /etc/inet/IPsecWebInitFile
Caution - Read the warning when you execute the ipsecconf command. A socket that is already latched, that is, a socket that is already in use, provides an unsecured back door into the system. For more extensive discussion, see Security Considerations for ipsecinit.conf and ipsecconf. The same warning applies to restarting the in.iked daemon. |
You can also reboot. Rebooting ensures that the IPsec policy is in effect on all TCP connections. At reboot, the TCP connections use the policy in the IPsec policy file.
Type the following policy in a remote system's ipsecinit.conf file:
# Communicate with web server about nonweb stuff # {laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
A remote system can communicate securely with the web server for nonweb traffic only when the systems' IPsec policies match.
You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments.
You must run the ipsecconf command in the global zone. For an exclusive-IP zone, you run the ipsecconf command in the non-global zone.
If you are running a release prior to the Solaris 10 4/09 release, the Network IPsec Management profile is not available. Use the Network Security profile.
To create a role that includes a network security profile and assign that role to a user, see How to Configure a Role for Network Security.
$ ipsecconf
The command displays each entry with an index followed by a number.
$ ipsecconf -l
$ ipsecconf -L
If you are specifying keys manually, the keying material must be random. The format for keying material for a Solaris system is hexadecimal. Other operating systems can require ASCII keying material. To generate keying material for a Solaris system that is communicating with an operating system that requires ASCII, see Example 23-1.
If your site has a random number generator, use that generator. Otherwise, you can use the od command with the /dev/random Solaris device as input. For more information, see the od(1) man page.
In the Solaris 10 4/09 release, you can also use the pktool command. The syntax of this command is simpler than the syntax of the od command. For details, see How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services.
% od -x|-X -A n file | head -n
Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4-character chunks.
Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8-character chunks.
Removes the input offset base from the display.
Serves as a source for random numbers.
Restricts the display to the first n lines of output.
Remove the spaces between the numbers on one line to create a 32-character key. A 32-character key is 128 bits. For a security parameter index (SPI), you should use an 8-character key. The key should use the 0x prefix.
Example 20-3 Generating Key Material for IPsec
The following example displays two lines of keys in groups of eight hexadecimal characters each.
% od -X -A n /dev/random | head -2 d54d1536 4a3e0352 0faf93bd 24fd6cad 8ecc2670 f3447465 20db0b0c c83f5a4b
By combining the four numbers on the first line, you can create a 32-character key. An 8-character number that is preceded by 0x provides a suitable SPI value, for example, 0xf3447465.
The following example displays two lines of keys in groups of four hexadecimal characters each.
% od -x -A n /dev/random | head -2 34ce 56b2 8b1b 3677 9231 42e9 80b0 c673 2f74 2817 8026 df68 12f4 905a db3d ef27
By combining the eight numbers on the first line, you can create a 32-character key.
The following procedure provides the keying material for the procedure, How to Secure Traffic Between Two Systems With IPsec. You are generating keys for two systems, partym and enigma. You generate the keys on one system, and then use the keys from the first system on both systems.
You must be in the global zone to manually manage keying material for a shared-IP zone.
You need three hexadecimal random numbers for outbound traffic and three hexadecimal random numbers for inbound traffic.
Therefore, one system needs to generate the following numbers:
Two hexadecimal random numbers as the value for the spi keyword. One number is for outbound traffic. One number is for inbound traffic. Each number can be up to eight characters long.
Two hexadecimal random numbers for the SHA1 algorithm for authentication. For a 160–bit key, each number must be 40 characters long. One number is for dst enigma. One number is for dst partym.
Two hexadecimal random numbers for the AES algorithm for ESP encryption. For a 256-bit key, each number must be 64 characters long. One number is for dst enigma. One number is for dst partym.
If you have a random number generator at your site, use the generator. You can also use the od command. See How to Generate Random Numbers on a Solaris System for the procedure.
The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
Note - Logging in remotely exposes security-critical traffic to eavesdropping. Even if you somehow protect the remote login, the security of the system is reduced to the security of the remote login session. Use the ssh command for a secure remote login.
# ipseckey >
The > prompt indicates that you are in ipseckey command mode.
> flush >
To prevent an adversary from having time to break your SAs, you need to replace the keying material.
Note - You must coordinate key replacement on communicating systems. When you replace the SAs on one system, the SAs must also be replaced on the remote system.
> add protocol spi random-hex-string \ src addr dst addr2 \ protocol-prefix_alg protocol-algorithm \ protocol-prefixkey random-hex-string-of-algorithm-specified-length
You also use this syntax to replace SAs that you have just flushed.
Specifies either esp or ah.
Specifies a random number of up to eight characters in hexadecimal format. Precede the characters with 0x. If you enter more numbers than the security parameter index (SPI) accepts, the system ignores the extra numbers. If you enter fewer numbers than the SPI accepts, the system pads your entry.
Specifies the IP address of one system.
Specifies the IP address of the peer system of addr.
Specifies one of encr or auth. The encr prefix is used with the esp protocol. The auth prefix is used with the ah protocol, and for authenticating the esp protocol.
Specifies an algorithm for ESP or AH. Each algorithm requires a key of a specific length.
Authentication algorithms include MD5 and SHA1. Starting in the Solaris 10 4/09 release, SHA256 and SHA512 are supported. Encryption algorithms include DES, 3DES, AES, and Blowfish.
Specifies a random hexadecimal number of the length that is required by the algorithm. For example, the MD5 algorithm requires a 32-character string for its 128-bit key. The 3DES algorithm requires a 48-character string for its 192-bit key.
Use the random numbers that you generated in Step 1.
For 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 >
Note - The peer system must use the same keying material and the same SPI.
Type the following commands to protect the 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 >
Note - The keys and SPI can be different for each SA. You should assign different keys and a different SPI for each SA.
In releases prior to the Solaris 10 4/09 release, this step ensures that the keying material is available to IPsec at reboot.
The lines of the /etc/inet/secret/ipseckeys file are identical to the ipseckey command line language.
# 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
Use the same keying material that was used on enigma.
The keying material on the two systems must be identical. As shown in the following example, only the comments in the ipseckeys file differ. The comments differ because dst enigma is inbound on the enigma system, and outbound on the partym system.
# 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
To replace keys in the current release, see Example 20-4.
Example 20-4 Replacing IPsec SAs
In this example, the administrator is configuring a system that is running the current Solaris 10 release. The administrator generates new keys, changes the keying information in the ipseckeys file, then restarts the service.
First, the administrator generates the keys by completing How to Generate Random Numbers on a Solaris System.
Then, the administrator uses the generated keys in the /etc/inet/secret/ipseckeys file.
The administrator used the same algorithms. Therefore, the administrator changes the values of SPI, encrkey and authkey only:
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
Finally, the administrator restarts the manual-key service. The restart command flushes the old keys before adding the new keys.
# svcadm restart manual-key
To verify that packets are protected, test the connection with the snoop command. The following prefixes can appear in the snoop output:
AH: Prefix indicates that AH is protecting the headers. You see AH: if you used auth_alg to protect the traffic.
ESP: Prefix indicates that encrypted data is being sent. You see ESP: if you used encr_auth_alg or encr_alg to protect the traffic.
You must be superuser or have assumed an equivalent role to create the snoop output. You must have access to both systems to test the connection.
% su - Password: Type root password #
In a terminal window on partym, snoop the packets from the enigma system.
# snoop -v enigma Using device /dev/hme (promiscuous mode)
In another terminal window, remotely log in to the enigma system. Provide your password. Then, become superuser and send a packet from the enigma system to the partym system. The packet should be captured by the snoop -v enigma command.
% ssh enigma Password: Type your password % su - Password: Type root password # ping partym
On the partym system, you should see output that includes AH and ESP information after the initial IP header information. AH and ESP information that resembles the following shows that packets are being protected:
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 ----- ...
If you are using role-based access control (RBAC) to administer your systems, you use this procedure to provide a network management role or network security role.
In the current release, the output appears similar to the following:
% 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...
If you are running a release prior to the Solaris 10 4/09 release, the output appears similar to the following:
% 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
The Network Management profile is a supplementary profile in the System Administrator profile. If you have included the System Administrator rights profile in a role, then that role can execute the commands in the Network Management profile.
% 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
The solaris policy commands run with privilege (privs=sys_net_config). The suser policy commands run as superuser (uid=0).
Use the definitions of the rights profiles in Step 1 to guide your decision.
A role with the Network Security or the Network IPsec Management rights profile, in addition to the Network Management profile, can execute the ifconfig, snoop, ipsecconf, and ipseckey commands, among others, with appropriate privilege.
To create the role, assign the role to a user, and register the changes with the name service, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
Example 20-5 Dividing Network Security Responsibilities Between Roles
In this example, the administrator divides network security responsibilities between two roles. One role administers wifi and link security and another role administers IPsec and IKE. Each role is assigned to three people, one person per shift.
The roles are created by the administrator as follows:
The administrator names the first role LinkWifi.
The administrator assigns the Network Wifi, Network Link Security, and Network Management rights profiles to the role.
Then, the administrator assigns the LinkWifi role to the appropriate users.
The administrator names the second role IPsec Administrator.
The administrator assigns the Network IPsec Management and the Network Management rights profiles to the role.
Then, the administrator assigns the IPsec Administrator role to the appropriate users.
The following steps provide the most likely uses of the SMF services for IPsec, IKE, and manual key management. By default, the policy and ipsecalgs services are enabled. Also by default, the ike and manual-key services are disabled.
# 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 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
# 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
Use the svcs service command to find the status of a service. If the service is in maintenance mode, follow the debugging suggestions in the output of the svcs -x service command.