Skip Navigation Links | |
Exit Print View | |
![]() |
Oracle Solaris Administration: IP Services Oracle Solaris 11 Information Library |
1. Planning the Network Deployment
2. Considerations When Using IPv6 Addresses
3. Configuring an IPv4 Network
4. Enabling IPv6 on the Network
5. Administering a TCP/IP Network
7. Troubleshooting Network Problems
11. Administering the ISC DHCP Service
12. Configuring and Administering the DHCP Client
13. DHCP Commands and Files (Reference)
14. IP Security Architecture (Overview)
16. IP Security Architecture (Reference)
Security Associations Database for IPsec
Utilities for SA Generation in IPsec
Security Considerations for ipseckey
17. Internet Key Exchange (Overview)
19. Internet Key Exchange (Reference)
20. IP Filter in Oracle Solaris (Overview)
Part IV Networking Performance
22. Integrated Load Balancer Overview
23. Configuration of Integrated Load Balancer (Tasks)
24. Virtual Router Redundancy Protocol (Overview)
25. VRRP Configuration (Tasks)
26. Implementing Congestion Control
Part V IP Quality of Service (IPQoS)
27. Introducing IPQoS (Overview)
28. Planning for an IPQoS-Enabled Network (Tasks)
29. Creating the IPQoS Configuration File (Tasks)
30. Starting and Maintaining IPQoS (Tasks)
31. Using Flow Accounting and Statistics Gathering (Tasks)
To enable the IPsec security policy when you start Oracle Solaris, you create a configuration file to initialize IPsec with your specific IPsec policy entries. The default name for this file is /etc/inet/ipsecinit.conf. See the ipsecconf(1M) man page for details about policy entries and their format. After the policy is configured, you can refresh the policy with the svcadm refresh ipsec/policy command.
The Oracle Solaris software includes a sample IPsec policy file, ipsecinit.sample. You can use the file as a template to create your own ipsecinit.conf file. The ipsecinit.sample file contains the following examples:
... # In the following simple example, outbound network traffic between the local # host and a remote host will be encrypted. Inbound network traffic between # these addresses is required to be encrypted as well. # # This example assumes that 10.0.0.1 is the IPv4 address of this host (laddr) # and 10.0.0.2 is the IPv4 address of the remote host (raddr). # {laddr 10.0.0.1 raddr 10.0.0.2} ipsec {encr_algs aes encr_auth_algs sha256 sa shared} # The policy syntax supports IPv4 and IPv6 addresses as well as symbolic names. # Refer to the ipsecconf(1M) man page for warnings on using symbolic names and # many more examples, configuration options and supported algorithms. # # This example assumes that 10.0.0.1 is the IPv4 address of this host (laddr) # and 10.0.0.2 is the IPv4 address of the remote host (raddr). # # The remote host will also need an IPsec (and IKE) configuration that mirrors # this one. # # The following line will allow ssh(1) traffic to pass without IPsec protection: {lport 22 dir both} bypass {} # # {laddr 10.0.0.1 dir in} drop {} # # Uncommenting the above line will drop all network traffic to this host unless # it matches the rules above. Leaving this rule commented out will allow # network packets that does not match the above rules to pass up the IP # network stack. ,,,
IPsec policy cannot be changed for established connections. A socket whose policy cannot be changed is called a latched socket. New policy entries do not protect sockets that are already latched. For more information, see the connect(3SOCKET) and accept(3SOCKET) man pages. If you are in doubt, restart the connection.
Protect your naming system. If the following two conditions are met, then your host names are no longer trustworthy:
Your source address is a host that can be looked up over the network.
Your naming system is compromised.
Security weaknesses often arise from the misapplication of tools, not from the actual tools. You should be cautious when using the ipsecconf command. Use ssh, or a console or other hard-connected TTY for the safest mode of operation.