test

System Administration Guide: IP Services

Part IV IP Security

This section focuses on network security. IP security architecture (IPsec) protects the network at the packet level. Internet key management (IKE) manages the keys for IPsec. Oracle Solaris IP filter provides a firewall.

Chapter 19 IP Security Architecture (Overview)

The IP Security Architecture (IPsec) provides cryptographic protection for IP datagrams in IPv4 and IPv6 network packets.

This chapter contains the following information:

To implement IPsec on your network, see Chapter 20, Configuring IPsec (Tasks). For reference information, see Chapter 21, IP Security Architecture (Reference).

What's New in IPsec?

Solaris 10 4/09: Starting in this release, the Service Management Facility (SMF) manages IPsec as a set of services.

By default, two IPsec services are enabled at system boot:

By default, the key management services are disabled at system boot:

To activate IPsec policies under SMF, you perform the following steps:

  1. Add IPsec policy entries to the ipsecinit.conf file.

  2. Configure the Internet Key Exchange (IKE) or manually configure keys.

  3. Refresh the IPsec policy service.

  4. Enable the key management service.

For more information about SMF, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also see the smf(5) and svcadm(1M) man pages.

Starting in this release, the ipsecconf and ipseckey commands have a -c option for checking the syntax of their respective configuration files. Also, the Network IPsec Management rights profile is provided for administering IPsec and IKE.

Solaris 10 7/07: Starting in this release, IPsec fully implements tunnels in tunnel mode, and the utilities that support tunnels are modified.

Solaris 10 1/06: Starting in this release, IKE is fully compliant with NAT-Traversal support as described in RFC 3947 and RFC 3948. IKE operations use the PKCS #11 library from the cryptographic framework, which improves performance.

The cryptographic framework provides a softtoken keystore for applications that use the metaslot. When IKE uses the metaslot, you have the option of storing the keys on disk, on an attached board, or in the softtoken keystore.

Introduction to IPsec

IPsec protects IP packets by authenticating the packets, by encrypting the packets, or by doing both. IPsec is performed inside the IP module, well below the application layer. Therefore, an Internet application can take advantage of IPsec while not having to configure itself to use IPsec. When used properly, IPsec is an effective tool in securing network traffic.

IPsec protection involves five main components:

IPsec applies the security mechanisms to IP datagrams that travel to the IP destination address. The receiver uses information in its SADB to verify that the arriving packets are legitimate and to decrypt them. Applications can invoke IPsec to apply security mechanisms to IP datagrams on a per-socket level as well.

Note that sockets behave differently from ports:

IPsec RFCs

The Internet Engineering Task Force (IETF) has published a number of Requests for Comment (RFCs) that describe the security architecture for the IP layer. All RFCs are copyrighted by the Internet Society. For a link to the RFCs, see http://www.ietf.org/. The following list of RFCs covers the more general IP security references:

IPsec Terminology

The IPsec RFCs define a number of terms that are useful to recognize when implementing IPsec on your systems. The following table lists IPsec terms, provides their commonly used acronyms, and defines each term. For a list of terminology used in key negotiation, see Table 22–1.

Table 19–1 IPsec Terms, Acronyms, and Uses

IPsec Term 

Acronym 

Definition 

Security association 

SA 

A unique connection between two nodes on a network. The connection is defined by a triplet: a security protocol, a security parameter index, and an IP destination. The IP destination can be an IP address or a socket. 

Security associations database 

SADB 

Database that contains all active security associations. 

Security parameter index 

SPI 

The indexing value for a security association. An SPI is a 32-bit value that distinguishes among SAs that have the same IP destination and security protocol. 

Security policy database

SPD 

Database that determines if outbound packets and inbound packets have the specified level of protection. 

Key exchange 

 

The process of generating keys for asymmetric cryptographic algorithms. The two main methods are RSA protocols and the Diffie-Hellman protocol. 

Diffie-Hellman protocol 

DH 

A key exchange protocol that involves key generation and key authentication. Often called authenticated key exchange.

RSA protocol 

RSA 

A key exchange protocol that involves key generation and key distribution. The protocol is named for its three creators, Rivest, Shamir, and Adleman. 

Internet Security Association and Key Management Protocol 

ISAKMP 

The common framework for establishing the format of SA attributes, and for negotiating, modifying, and deleting SAs. ISAKMP is the IETF standard for handling IPsec SAs. 

IPsec Packet Flow

Figure 19–1 shows how an IP addressed packet, as part of an IP datagram, proceeds when IPsec has been invoked on an outbound packet. The flow diagram illustrates where authentication header (AH) and encapsulating security payload (ESP) entities can be applied to the packet. How to apply these entities, as well as how to choose the algorithms, are described in subsequent sections.

Figure 19–2 shows the IPsec inbound process.

Figure 19–1 IPsec Applied to Outbound Packet Process

Flow diagram shows that the outbound packet is first protected by ESP, and then by AH. The packet then goes to a tunnel or a physical interface.

Figure 19–2 IPsec Applied to Inbound Packet Process

Flow diagram shows that IPsec first processes the AH header, then the ESP header on inbound packets. A packet that is not protected enough is dropped.

IPsec Security Associations

An IPsec security association (SA) specifies security properties that are recognized by communicating hosts. A single SA protects data in one direction. The protection is either to a single host or to a group (multicast) address. Because most communication is either peer-to-peer or client-server, two SAs must be present to secure traffic in both directions.

The following three elements uniquely identify an IPsec SA:

The SPI, an arbitrary 32-bit value, is transmitted with an AH or ESP packet. The ipsecah(7P) and ipsecesp(7P) man pages explain the extent of protection that is provided by AH and ESP. An integrity checksum value is used to authenticate a packet. If the authentication fails, the packet is dropped.

Security associations are stored in a security associations database (SADB). A socket-based administration engine, the PF_KEY interface enables privileged applications to manage the database. For example, the IKE application and the ipseckeys command use the PF_KEY socket interface.

Key Management in IPsec

Security associations (SAs) require keying material for authentication and for encryption. The managing of this keying material is called key management. The Internet Key Exchange (IKE) protocol handles key management automatically. You can also manage keys manually with the ipseckey command.

SAs on IPv4 and IPv6 packets can use either method of key management. Unless you have an overriding reason to use manual key management, automatic key management is preferred. For example, to interoperate with systems other than Solaris systems might require manual key management.

In the current release, SMF provides the following key management services for IPsec:

In the releases prior to the Solaris 10 4/09 release, the in.iked and ipseckey commands manage keying material.

IPsec Protection Mechanisms

IPsec provides two security protocols for protecting data:

An AH protects data with an authentication algorithm. An ESP protects data with an encryption algorithm. Optionally, an ESP protects data with an authentication algorithm. Each implementation of an algorithm is called a mechanism.

Authentication Header

The authentication header provides data authentication, strong integrity, and replay protection to IP datagrams. AH protects the greater part of the IP datagram. As the following illustration shows, AH is inserted between the IP header and the transport header.

Diagram shows the AH header between the IP header and the TCP header.

The transport header can be TCP, UDP, SCTP, or ICMP. If a tunnel is being used, the transport header can be another IP header.

Encapsulating Security Payload

The encapsulating security payload (ESP) module provides confidentiality over what the ESP encapsulates. ESP also provides the services that AH provides. However, ESP only provides its protections over the part of the datagram that ESP encapsulates. ESP provides optional authentication services to ensure the integrity of the protected packet. Because ESP uses encryption-enabling technology, a system that provides ESP can be subject to import and export control laws.

ESP encapsulates its data, so ESP only protects the data that follows its beginning in the datagram, as shown in the following illustration.

Diagram shows the ESP header between the IP header and the TCP header. The TCP header is encrypted by the ESP header.

In a TCP packet, ESP encapsulates only the TCP header and its data. If the packet is an IP-in-IP datagram, ESP protects the inner IP datagram. Per-socket policy allows self-encapsulation, so ESP can encapsulate IP options when ESP needs to.

If self-encapsulation is set, a copy of the IP header is made to construct an IP-in-IP datagram. For example, when self-encapsulation is not set on a TCP socket, the datagram is sent in the following format:


[ IP(a -> b) options + TCP + data ]

When self-encapsulation is set on that TCP socket, the datagram is sent in the following format:


[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ]

For further discussion, see Transport and Tunnel Modes in IPsec.

Security Considerations When Using AH and ESP

The following table compares the protections that are provided by AH and ESP.

Table 19–2 Protections Provided by AH and ESP in IPsec

Protocol 

Packet Coverage 

Protection 

Against Attacks 

AH 

Protects packet from the IP header to the transport header 

Provides strong integrity, data authentication: 

  • Ensures that the receiver receives exactly what the sender sent

  • Is susceptible to replay attacks when an AH does not enable replay protection

Replay, cut-and-paste 

ESP 

Protects packet following the beginning of ESP in the datagram. 

With encryption option, encrypts the IP datagram. Ensures confidentiality 

Eavesdropping 

With authentication option, provides the same protection as AH 

Replay, cut-and-paste 

With both options, provides strong integrity, data authentication, and confidentiality 

Replay, cut-and-paste, eavesdropping 

Authentication and Encryption Algorithms in IPsec

IPsec security protocols use two types of algorithms, authentication and encryption. The AH module uses authentication algorithms. The ESP module can use encryption as well as authentication algorithms. You can obtain a list of the algorithms on your system and their properties by using the ipsecalgs command. For more information, see the ipsecalgs(1M) man page. You can also use the functions that are described in the getipsecalgbyname(3NSL) man page to retrieve the properties of algorithms.

IPsec on a Solaris system uses the Solaris cryptographic framework to access the algorithms. The framework provides a central repository for algorithms, in addition to other services. The framework enables IPsec to take advantage of high performance cryptographic hardware accelerators. The framework also provides resource control features. For example, the framework enables you to limit the amount of CPU time spent in cryptographic operations in the kernel.

For more information, see the following:

Authentication Algorithms in IPsec

Authentication algorithms produce an integrity checksum value or digest that is based on the data and a key. The AH module uses authentication algorithms. The ESP module can use authentication algorithms as well.

Encryption Algorithms in IPsec

Encryption algorithms encrypt data with a key. The ESP module in IPsec uses encryption algorithms. The algorithms operate on data in units of a block size.

Different releases of the Solaris 10 OS provide different default encryption algorithms.

Caution – Caution –

Starting in the Solaris 10 7/07 release, do not add the Solaris Encryption Kit to your system. The kit downgrades the patch level for encryption on your system. The kit is incompatible with the encryption on your system.

IPsec Protection Policies

IPsec protection policies can use any of the security mechanisms. IPsec policies can be applied at the following levels:

IPsec applies the system-wide policy to outbound datagrams and inbound datagrams. Outbound datagrams are either sent with protection or without protection. If protection is applied, the algorithms are either specific or non-specific. You can apply some additional rules to outbound datagrams, because of the additional data that is known by the system. Inbound datagrams can be either accepted or dropped. The decision to drop or accept an inbound datagram is based on several criteria, which sometimes overlap or conflict. Conflicts are resolved by determining which rule is parsed first. The traffic is automatically accepted, except when a policy entry states that traffic should bypass all other policies.

The policy that normally protects a datagram can be bypassed. You can either specify an exception in the system-wide policy, or you can request a bypass in the per-socket policy. For traffic within a system, policies are enforced, but actual security mechanisms are not applied. Instead, the outbound policy on an intra-system packet translates into an inbound packet that has had those mechanisms applied.

You use the ipsecinit.conf file and the ipsecconf command to configure IPsec policies. For details and examples, see the ipsecconf(1M) man page.

Transport and Tunnel Modes in IPsec

The IPsec standards define two distinct modes of IPsec operation, transport mode and tunnel mode. The modes do not affect the encoding of packets. The packets are protected by AH, ESP, or both in each mode. The modes differ in policy application when the inner packet is an IP packet, as follows:

In transport mode, the outer header, the next header, and any ports that the next header supports, can be used to determine IPsec policy. In effect, IPsec can enforce different transport mode policies between two IP addresses to the granularity of a single port. For example, if the next header is TCP, which supports ports, then IPsec policy can be set for a TCP port of the outer IP address. Similarly, if the next header is an IP header, the outer header and the inner IP header can be used to determine IPsec policy.

Tunnel mode works only for IP-in-IP datagrams. Tunneling in tunnel mode can be useful when computer workers at home are connecting to a central computer location. In tunnel mode, IPsec policy is enforced on the contents of the inner IP datagram. Different IPsec policies can be enforced for different inner IP addresses. That is, the inner IP header, its next header, and the ports that the next header supports, can enforce a policy. Unlike transport mode, in tunnel mode the outer IP header does not dictate the policy of its inner IP datagram.

Therefore, in tunnel mode, IPsec policy can be specified for subnets of a LAN behind a router and for ports on those subnets. IPsec policy can also be specified for particular IP addresses, that is, hosts, on those subnets. The ports of those hosts can also have a specific IPsec policy. However, if a dynamic routing protocol is run over a tunnel, do not use subnet selection or address selection because the view of the network topology on the peer network could change. Changes would invalidate the static IPsec policy. For examples of tunneling procedures that include configuring static routes, see Protecting a VPN With IPsec.

In the Solaris OS, tunnel mode can be enforced only on an IP tunneling network interface.The ipsecconf command provides a tunnel keyword to select an IP tunneling network interface. When the tunnel keyword is present in a rule, all selectors that are specified in that rule apply to the inner packet.

In transport mode, ESP, AH, or both, can protect the datagram.

The following figure shows an IP header with an unprotected TCP packet.

Figure 19–3 Unprotected IP Packet Carrying TCP Information

Diagram shows the IP header followed by the TCP header. The TCP header is not protected.

In transport mode, ESP protects the data as shown in the following figure. The shaded area shows the encrypted part of the packet.

Figure 19–4 Protected IP Packet Carrying TCP Information

Diagram shows the ESP header between the IP header and the TCP header. The TCP header is encrypted by the ESP header.

In transport mode, AH protects the data as shown in the following figure.

Figure 19–5 Packet Protected by an Authentication Header

Diagram shows the AH header between the IP header and the TCP header.

AH actually covers the data before the data appears in the datagram. Consequently, the protection that is provided by AH, even in transport mode, covers some of the IP header.

In tunnel mode, the entire datagram is inside the protection of an IPsec header. The datagram in Figure 19–3 is protected in tunnel mode by an outer IPsec header, and in this case ESP, as is shown in the following figure.

Figure 19–6 IPsec Packet Protected in Tunnel Mode

Diagram shows the ESP header after the IP header and before an IP header and a TCP header. The last 2 headers are protected by encryption.

The ipsecconf command includes keywords to set tunnels in tunnel mode or transport mode.

Virtual Private Networks and IPsec

A configured tunnel is a point-to-point interface. The tunnel enables one IP packet to be encapsulated within another IP packet. A correctly configured tunnel requires both a tunnel source and a tunnel destination. For more information, see the tun(7M) man page and Configuring Tunnels for IPv6 Support.

A tunnel creates an apparent physical interface to IP. The physical link's integrity depends on the underlying security protocols. If you set up the security associations (SAs) securely, then you can trust the tunnel. Packets that exit the tunnel must have originated from the peer that was specified in the tunnel destination. If this trust exists, you can use per-interface IP forwarding to create a virtual private network (VPN).

You can use IPsec to construct a VPN. IPsec secures the connection. For example, an organization that uses VPN technology to connect offices with separate networks can deploy IPsec to secure traffic between the two offices.

The following figure illustrates how two offices use the Internet to form their VPN with IPsec deployed on their network systems.

Figure 19–7 Virtual Private Network

Diagram shows that Offices 1 and 2 use the hme0 interface to communicate with each other. Each office uses hme1 for internal communication.

For a detailed example of the setup procedure, see How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

For a similar example with IPv6 addresses, see How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6.

IPsec and NAT Traversal

IKE can negotiate IPsec SAs across a NAT box. This ability enables systems to securely connect from a remote network, even when the systems are behind a NAT device. For example, employees who work from home, or who log on from a conference site can protect their traffic with IPsec.

NAT stands for network address translation. A NAT box is used to translate a private internal address into a unique Internet address. NATs are very common at public access points to the Internet, such as hotels. For a fuller discussion, see Using Oracle Solaris IP Filter's NAT Feature.

The ability to use IKE when a NAT box is between communicating systems is called NAT traversal, or NAT-T. In the Solaris 10 release, NAT-T has the following limitations:

The following RFCs describe NAT functionality and the limits of NAT-T. Copies of the RFCs can be retrieved from http://www.rfc-editor.org.

To use IPsec across a NAT, see Configuring IKE for Mobile Systems (Task Map).

IPsec and SCTP

The Solaris OS supports the Streams Control Transmission Protocol (SCTP). The use of the SCTP protocol and SCTP port number to specify IPsec policy is supported, but is not robust. The IPsec extensions for SCTP as specified in RFC 3554 are not yet implemented. These limitations can create complications in creating IPsec policy for SCTP.

SCTP can make use of multiple source and destination addresses in the context of a single SCTP association. When IPsec policy is applied to a single source or a single destination address, communication can fail when SCTP switches the source or the destination address of that association. IPsec policy only recognizes the original address. For information about SCTP, read the RFCs and SCTP Protocol.

IPsec and Solaris Zones

For shared-IP zones, IPsec is configured from the global zone. The IPsec policy configuration file, ipsecinit.conf, exists in the global zone only. The file can have entries that apply to non-global zones, as well as entries that apply to the global zone.

For exclusive-IP zones, IPsec is configured in the non-global zone.

For information about how to use IPsec with zones, see Protecting Traffic With IPsec. For information about zones, see Chapter 16, Introduction to Solaris Zones, in System Administration Guide: Oracle Solaris Containers-Resource Management and Oracle Solaris Zones.

IPsec and Logical Domains

IPsec works with logical domains. The logical domain must be running a version of the Solaris OS that includes IPsec, such as the Solaris 10 release.

To create logical domains, you must use the Oracle VM Server for SPARC, which was previously called Logical Domains. For information about how to configure logical domains, see Logical Domains 1.2 Administration Guide or Oracle VM Server for SPARC 2.0 Administration Guide.

IPsec Utilities and Files

Table 19–3 describes the files, commands, and service identifiers that are used to configure and manage IPsec. For completeness, the table includes key management files, socket interfaces, and commands.

Starting in the Solaris 10 4/09 release, IPsec is managed by SMF. For more information about service identifiers, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.

Table 19–3 List of Selected IPsec Utilities and Files

IPsec Utility, File, or Service 

Description 

Man Page 

svc:/network/ipsec/ipsecalgs

In the current release, the SMF service that manages IPsec algorithms. 

smf(5), ipsecalgs(1M)

svc:/network/ipsec/manual-key

In the current release, the SMF service that manages manual security associations (SAs). 

smf(5), ipseckey(1M)

svc:/network/ipsec/policy

In the current release, the SMF service that manages IPsec policy.

smf(5), ipsecconf(1M)

svc:/network/ipsec/ike

In the current release, the SMF service for the automatic management of IPsec SAs. 

smf(5), in.iked(1M)

/etc/inet/ipsecinit.conf file

IPsec policy file. In releases prior to the Solaris 10 4/09 release, if this file exists, IPsec is activated at boot time.

In the current release, the SMF policy service uses this file to configure IPsec policy at system boot.

ipsecconf(1M)

ipsecconf command

IPsec policy command. Useful for viewing and modifying the current IPsec policy, and for testing. In releases prior to the Solaris 10 4/09 release, the boot scripts use ipsecconf to read the /etc/inet/ipsecinit.conf file and activate IPsec.

In the current release, ipsecconf is used by the SMF policy service to configure IPsec policy at system boot.

ipsecconf(1M)

PF_KEY socket interface

Interface for the security associations database (SADB). Handles manual key management and automatic key management.

pf_key(7P)

ipseckey command

IPsec SAs keying command. ipseckey is a command-line front end to the PF_KEY interface. ipseckey can create, destroy, or modify SAs.

ipseckey(1M)

/etc/inet/secret/ipseckeys file

Keys for IPsec SAs. In releases prior to the Solaris 10 4/09 release, if the ipsecinit.conf file exists, the ipseckeys file is automatically read at boot time.

In the current release, ipseckeys is used by the SMF manual-key service to configure SAs manually at system boot.

 

ipsecalgs command

IPsec algorithms command. Useful for viewing and modifying the list of IPsec algorithms and their properties.

In the current release, is used by the SMF ipsecalgs service to synchronize known IPsec algorithms with the kernel at system boot.

ipsecalgs(1M)

/etc/inet/ipsecalgs file

Contains the configured IPsec protocols and algorithm definitions. This file is managed by the ipsecalgs command and must never be edited manually.

 

/etc/inet/ike/config file

IKE configuration and policy file. By default, this file does not exist. In releases prior to the Solaris 10 4/09 release, if this file exists, the IKE daemon, in.iked, provides automatic key management. The management is based on rules and global parameters in the /etc/inet/ike/config file. See IKE Utilities and Files.

In the current release, if this file exists, the svc:/network/ipsec/ike service starts the IKE daemon, in.iked, to provide automatic key management.

ike.config(4)

Changes to IPsec for the Solaris 10 Release

For a complete listing of new Solaris features and a description of Solaris releases, see Oracle Solaris 10 9/10 What’s New. Since the Solaris 9 release, IPsec includes the following functionality:

Chapter 20 Configuring IPsec (Tasks)

This chapter provides procedures for implementing IPsec on your network. The procedures are described in the following task maps:

For overview information about IPsec, see Chapter 19, IP Security Architecture (Overview). For reference information about IPsec, see Chapter 21, IP Security Architecture (Reference).

Protecting Traffic With IPsec (Task Map)

The following task map points to procedures that set up IPsec between one or more systems. The ipsecconf(1M), ipseckey(1M), and ifconfig(1M) man pages also describe useful procedures in their respective Examples sections.

Task 

Description 

For Instructions 

Secure traffic between two systems. 

Protects packets from one system to another system. 

How to Secure Traffic Between Two Systems With IPsec

Secure a web server by using IPsec policy. 

Requires non-web traffic to use IPsec. Web clients are identified by particular ports, which bypass IPsec checks. 

How to Use IPsec to Protect a Web Server From Nonweb Traffic

Display IPsec policies. 

Displays the IPsec policies that are currently being enforced, in the order in which the policies are enforced. 

How to Display IPsec Policies

Generate random numbers. 

Generates random numbers for keying material for manually created security associations. 

How to Generate Random Numbers on a Solaris System

How to Generate a Symmetric Key by Using the pktool Command in System Administration Guide: Security Services

Create or replace security associations manually. 

Provides the raw data for security associations: 

  • IPsec algorithm name and keying material

  • Key for the security parameter index

  • IP source and destination addresses

How to Manually Create IPsec Security Associations

Check that IPsec is protecting the packets. 

Examines snoop output for specific headers that indicate how the IP datagrams are protected.

How to Verify That Packets Are Protected With IPsec

(Optional) Create a Network Security role. 

Creates a role that can set up a secure network, but has fewer powers than superuser. 

How to Configure a Role for Network Security

Manage IPsec and keying material as a set of SMF services. 

Describes when and how to use the commands that enable, disable, refresh, and restart services. Also describes the commands that change the property values of services. 

How to Manage IKE and IPsec Services

Set up a secure virtual private network (VPN). 

Sets up IPsec between two systems that are separated by the Internet. 

Protecting a VPN With IPsec (Task Map)

Protecting Traffic With IPsec

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:

ProcedureHow to Secure Traffic Between Two Systems With IPsec

This procedure assumes the following setup:

Before You Begin

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.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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.

  2. On each system, check host entries.

    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.

    1. On a system that is named enigma, type the following in the hosts or ipnodes file:


      # Secure communication with partym
192.168.13.213 partym
2001::eeee:3333:3333 partym

    2. On a system that is named partym, type the following in the hosts or ipnodes file:


      # Secure communication with enigma
192.168.116.16 enigma
2001::aaaa:6666:6666 enigma

    Using the naming services for symbolic names is insecure.

  3. On each system, create the IPsec policy file.

    The file name is /etc/inet/ipsecinit.conf. For an example, see the /etc/inet/ipsecinit.sample file.

  4. Add an IPsec policy entry to the ipsecinit.conf file.

    1. On the enigma system, add the following policy:


      {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. On the partym system, add the identical policy:


      {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.

  5. On each system, add a pair of IPsec SAs between the two systems.

    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.

  6. Enable IPsec policy.

  7. Verify the syntax of the IPsec policy file.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

    Fix any errors, verify the syntax of the file, and continue.

  8. Refresh the IPsec policy.


    # 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

  9. Activate the keys for IPsec.

    • If you configured IKE in Step 5, do one of the following:

      • If the ike service is not enabled, enable it.


        # svcadm enable svc:/network/ipsec/ike:default

      • If the ike service is enabled, restart it.


        # svcadm restart svc:/network/ipsec/ike:default

    • If you manually configured keys in Step 5, do one of the following:

      • If the manual-key service is not enabled, enable it.


        # svcadm enable svc:/network/ipsec/manual-key:default

      • If the manual-key service is enabled, refresh it.


        # svcadm refresh svc:/network/ipsec/manual-key:default

  10. Verify that packets are being protected.

    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.

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:

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.

ProcedureHow to Use IPsec to Protect a Web Server From Nonweb Traffic

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.

Before You Begin

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:

  1. On the system console, assume the Primary Administrator role or become superuser.

    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.

  2. Determine which services need to bypass security policy checks.

    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.

  3. Create IPsec policy for the web server and enable it.

    • Starting in the Solaris 10 4/09 release, follow the steps from Step 4 to Step 7.

    • If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 8 to Step 11.

    Step 12 is optional in all Solaris releases.

  4. Add the web server policy to the IPsec policy file.

    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.

  5. Verify the syntax of the IPsec policy file.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. Refresh the IPsec policy.


    # svcadm refresh svc:/network/ipsec/policy:default

  7. Refresh the keys for IPsec.

    Your setup is complete. Optionally, you can perform Step 12.

  8. Create a file in the /etc/inet directory for the web server policy.

    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.

  9. Copy the contents of the file that you created in Step 8 into the /etc/inet/ipsecinit.conf file.

  10. Protect the IPsecWebInitFile file with read-only permissions.


    # chmod 400 IPsecWebInitFile

  11. Secure the web server without rebooting.

    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 – 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.

  12. (Optional) Enable a remote system to communicate with the web server for nonweb traffic.

    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.

ProcedureHow to Display IPsec Policies

You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments.

Before You Begin

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.

  1. Assume a role that includes the Network IPsec Management profile, or become superuser.

    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.

  2. Display IPsec policies.

    1. Display the global IPsec policy entries in the order that the entries were added.


      $ ipsecconf

      The command displays each entry with an index followed by a number.

    2. Display the IPsec policy entries in the order in which a match occurs.


      $ ipsecconf -l

    3. Display the IPsec policy entries, including per-tunnel entries, in the order in which a match occurs.


      $ ipsecconf -L

ProcedureHow to Generate Random Numbers on a Solaris System

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.

  1. Generate random numbers in hexadecimal format.


    % od -x|-X -A n file | head -n
    -x

    Displays the octal dump in hexadecimal format. Hexadecimal format is useful for keying material. The hexadecimal is printed in 4-character chunks.

    -X

    Displays the octal dump in hexadecimal format. The hexadecimal is printed in 8-character chunks.

    -A n

    Removes the input offset base from the display.

    file

    Serves as a source for random numbers.

    head -n

    Restricts the display to the first n lines of output.

  2. Combine the output to create a key of the appropriate length.

    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.

ProcedureHow to Manually Create IPsec Security Associations

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.

Before You Begin

You must be in the global zone to manually manage keying material for a shared-IP zone.

  1. Generate the keying material for the SAs.

    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.

  2. On the system console on one of the systems, assume the Primary Administrator role or become superuser.

    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.

  3. Create the SAs.

    • Starting in the Solaris 10 4/09 release, follow the steps from Step 8 to Step 10.

    • If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 4 to Step 9.

  4. Enable the ipseckey command mode.


    # ipseckey

>

    The > prompt indicates that you are in ipseckey command mode.

  5. If you are replacing existing SAs, flush the current SAs.


    > 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.

  6. To create SAs, type the following command.


    > 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.

    protocol

    Specifies either esp or ah.

    random-hex-string

    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.

    addr

    Specifies the IP address of one system.

    addr2

    Specifies the IP address of the peer system of addr.

    protocol-prefix

    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.

    protocol-algorithm

    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.

    random-hex-string-of-algorithm-specified-length

    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.

    1. For example, on the enigma system, protect outbound packets.

      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.

    2. Still in ipseckey command mode on the enigma system, protect inbound packets.

      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.

  7. To exit ipseckey command mode, press Control-D or type quit.

  8. Add the keying material to the /etc/inet/secret/ipseckeys file.

    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.

    1. For example, the /etc/inet/secret/ipseckeys file on the enigma system would appear similar to the following:


      # 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

    2. Protect the file with read-only permissions.


      # chmod 400 /etc/inet/secret/ipseckeys

  9. Repeat the procedure on the partym system.

    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

  10. Enable the manual-key service.


    # 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.

ProcedureHow to Verify That Packets Are Protected With IPsec

To verify that packets are protected, test the connection with the snoop command. The following prefixes can appear in the snoop output:

Before You Begin

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.

  1. On one system, such as partym, become superuser.


    % su -
Password: Type root password
#

  2. From the partym system, prepare to snoop packets from a remote system.

    In a terminal window on partym, snoop the packets from the enigma system.


    # snoop -v enigma
Using device /dev/hme (promiscuous mode)

  3. Send a packet from the remote system.

    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

  4. Examine the snoop output.

    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 -----
...

ProcedureHow to Configure a Role for Network Security

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.

  1. Find the Network rights profiles in the local prof_attr database.

    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.

  2. Determine which commands are in the Network Management rights 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).

  3. Decide the scope of the network security roles at your site.

    Use the definitions of the rights profiles in Step 1 to guide your decision.

    • To create a role that handles all network security, use the Network Security rights profile.

    • In the current release, to create a role that handles IPsec and IKE only, use the Network IPsec Management rights profile.

  4. Create a network security role that includes the Network Management rights profile.

    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:

ProcedureHow to Manage IKE and IPsec Services

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.

  1. To manage IPsec policy, do one of the following:

    • After adding new policies to the ipsecinit.conf file, refresh the policy service.


      # svcadm refresh svc:/network/ipsec/policy

    • After changing the value of a service property, view the property value, then refresh and restart the policy service.


      # 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

  2. To automatically manage keys, do one of the following:

    • After adding entries to the /etc/inet/ike/config file, enable the ike service.


      # svcadm enable svc:/network/ipsec/ike

    • After changing entries in the /etc/inet/ike/config file, refresh the ike service.


      # svcadm refresh svc:/network/ipsec/ike

    • After changing the value of a service property, view the property value, then refresh and restart the service.


      # 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

    • To stop the ike service, disable it.


      # svcadm disable svc:/network/ipsec/ike

  3. To manually manage keys, do one of the following:

    • After adding entries to the /etc/inet/secret/ipseckeys file, enable the manual-key service.


      # svcadm enable svc:/network/ipsec/manual-key

    • After changing the ipseckeys file, refresh the service.


      # svcadm refresh manual-key

    • After changing the value of a service property, view the property value, then refresh and restart the service.


      # 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

    • To prevent manual key management, disable the manual-key service.


      # svcadm disable svc:/network/ipsec/manual-key

  4. If you modify the IPsec protocols and algorithms table, refresh the ipsecalgs service.


    # svcadm refresh svc:/network/ipsec/ipsecalgs
Troubleshooting

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.

Protecting a VPN With IPsec

IPsec tunnels can protect a VPN. In the Solaris 10 7/07 release, a tunnel can be in tunnel mode or transport mode. Tunnel mode is interoperable with the implementation of IPsec by other vendors. Transport mode is interoperable with earlier versions of the Solaris OS. For a discussion of tunnel modes, see Transport and Tunnel Modes in IPsec.

Tunnels in tunnel mode offer more fine-grained control of the traffic. In tunnel mode, for an inner IP address, you can specify the particular protection you want, down to a single port.

Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode

Figure 20–1 IPsec Tunnel Diagram

Diagram shows a VPN that connects two LANs. Each LAN has four subnets.

The following examples assume that the tunnel is configured for all subnets of the LANs:


## Tunnel configuration ##
# Tunnel name is ip.tun0
# Intranet point for the source is 10.1.2.1
# Intranet point for the destination is 10.2.3.1
# Tunnel source is 192.168.1.10
# Tunnel destination is 192.168.2.10
Example 20–6 Creating a Tunnel That All Subnets Can Use

In this example, all traffic from the local LANs of the Central LAN in Figure 20–1 can be tunneled through Router 1 to Router 2, and then delivered to all local LANs of the Overseas LAN. The traffic is encrypted with AES.


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
Example 20–7 Creating a Tunnel That Connects Two Subnets Only

In this example, only traffic between subnet 10.1.2.0/24 of the Central LAN and subnet 10.2.3.0/24 of the Overseas LAN is tunneled and encrypted. In the absence of other IPsec policies for Central, if the Central LAN attempts to route any traffic for other LANs over this tunnel, the traffic is dropped at Router 1.


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs aes encr_auth_algs md5 sha1 shared}
Example 20–8 Creating a Tunnel for Email Traffic Only Between Two Subnets

In this example, a tunnel is created for email traffic only. The traffic is delivered from subnet 10.1.2.0/24 of the Central LAN to the email server on the 10.2.3.0/24 subnet of the Overseas LAN. The email is encrypted with Blowfish. The policies apply to the remote and local email ports. The rport policy protects email that Central sends to the remote email port of Overseas. The lport policy protects email that Central receives from Overseas on local port 25.


## IPsec policy for email from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

## IPsec policy for email from Overseas to Central ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
Example 20–9 Creating a Tunnel for FTP Traffic for All Subnets

In this example, IPsec policy protects the FTP ports in Figure 20–1 with AES for all subnets of the Central LAN to all subnets of the Overseas LAN. This configuration works for the active mode of FTP.


## IPsec policy for outbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Protecting a VPN With IPsec (Task Map)

The following task map points to procedures that configure IPsec to protect traffic across the Internet. These procedures set up a secure virtual private network (VPN) between two systems that are separated by the Internet. One common use of this technology is to protect traffic between home workers and their corporate office.

Task 

Description 

For Instructions 

Protect tunnel traffic in tunnel mode over IPv4. 

Protects traffic in tunnel mode between two Solaris 10 systems, two Oracle Solaris systems, or between a Solaris 10 system and an Oracle Solaris Express system. The Solaris 10 system must be running at least the Solaris 10 7/07 release. 

Also, protects traffic in tunnel mode between a Solaris 10 system or an Oracle Solaris Express system, and a system that is running on another platform. The Solaris 10 system must be running at least the Solaris 10 7/07 release. 

How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4

Protect tunnel traffic in tunnel mode over IPv6. 

Protects traffic in tunnel mode between two Oracle Solaris systems that are using the IPv6 protocol. 

How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6

Protect tunnel traffic in transport mode over IPv4. 

Protects traffic in transport mode between two Solaris 10 systems, two Solaris systems, or between a Solaris 10 system and an Oracle Solaris system. The Solaris 10 system must be running at least the Solaris 10 7/07 release. 

Also, protects traffic in transport mode between a system that is running an earlier version of the Solaris OS and a Solaris 10 or an Oracle Solaris system. The Solaris 10 system must be running at least the Solaris 10 7/07 release. 

How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4

Protects traffic by using an older, deprecated syntax. This method is useful when you are communicating with a system that is running an earlier version of the Solaris OS. This method simplifies comparing the configuration files on the two systems. 

Example 20–11

Example 20–16

Protect tunnel traffic in transport mode over IPv6. 

Protects traffic in transport mode between two Oracle Solaris systems that are using the IPv6 protocol. 

How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6

Prevent IP spoofing. 

Creates an SMF service to prevent the system from forwarding packets across a VPN without decrypting the packets. 

How to Prevent IP Spoofing

Description of the Network Topology for the IPsec Tasks to Protect a VPN

The procedures that follow this section assume the following setup. For a depiction of the network, see Figure 20–2.

Figure 20–2 Sample VPN Between Offices Separated by the Internet

Diagram shows details of VPN between Europe and California offices.

As the preceding illustration shows, the procedures for the IPv4 network use the following configuration parameters.

Parameter 

Europe 

California 

System name 

 

enigma
 

partym

System intranet interface 

 

hme1
 

hme1

System intranet address, also the -point address in Step 7 


10.16.16.6
 

10.1.3.3

System Internet interface 

 

hme0
 

hme0

System Internet address, also the tsrc address in Step 7 


192.168.116.16
 

192.168.13.213

Name of Internet router 

 

router-E
 

router-C

Address of Internet router 

 

192.168.116.4
 

192.168.13.5

Tunnel name 

 

ip.tun0
 

ip.tun0

The following IPv6 addresses are used in the procedures. The tunnel names are the same.

Parameter 

Europe 

California 

System intranet address 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

System Internet address 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Address of Internet router 

 

2001::aaaa:0:4
 

2001::eeee:0:1

ProcedureHow to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4

In tunnel mode, the inner IP packet determines the IPsec policy that protects its contents.

This procedure extends the procedure How to Secure Traffic Between Two Systems With IPsec. The setup is described in Description of the Network Topology for the IPsec Tasks to Protect a VPN.

Note –

Perform the steps in this procedure on both systems.

In addition to connecting two systems, you are connecting two intranets that connect to these two systems. The systems in this procedure function as gateways.

Before You Begin

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.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Control the flow of packets before configuring IPsec.

    1. Ensure that IP forwarding and IP dynamic routing are disabled.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

      Turning off IP forwarding prevents packets from being forwarded from one network to another network through this system. For a description of the routeadm command, see the routeadm(1M) man page.

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      Turning on IP strict destination multihoming ensures that packets for one of the system's destination addresses arrive at the correct destination address.

      When strict destination multihoming is enabled, packets that arrive on a particular interface must be addressed to one of the local IP addresses of that interface. All other packets, even packets that are addressed to other local addresses of the system, are dropped.

      Caution – Caution –

      The multihoming value reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

    3. Disable most network services, and possibly all network services.

      Note –

      If your system was installed with the “limited” SMF profile, then you can skip this step. Network services, with the exception of Solaris Secure Shell, are disabled.

      The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

      Choose one of the following options:

      • If you are running the Solaris 10 11/06 release or a later release, run the “limited” SMF profile.


        # netservices limited

      • Otherwise, individually disable network services.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

    4. Verify that most network services are disabled.

      Verify that loopback mounts and the ssh service are running.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy.

    Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN. To strengthen the policy, see Example 20–12. For additional examples, see Examples of Protecting a VPN With IPsec by Using Tunnels in Tunnel Mode.

    In this policy, IPsec protection is not required between systems on the local LAN and the internal IP address of the gateway, so a bypass statement is added.

    1. On the enigma system, type the following entry into the ipsecinit.conf file:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. On the partym system, type the following entry into the ipsecinit.conf file:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Optional) Verify the syntax of the IPsec policy file.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:

    • Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.

    • If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

  7. Configure the tunnel, ip.tun0, in the /etc/hostname.ip.tun0 file.

    The syntax of the file is the following:


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. On the enigma system, add the following entry to the hostname.ip.tun0 file:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. On the partym system, add the following entry to the hostname.ip.tun0 file:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Protect the tunnel with the IPsec policy that you created.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. To read the contents of the tunnel configuration file into the kernel, restartRestart the network services.


    # svcadm restart svc:/network/initial:default

  10. Turn on IP forwarding for the hme1 interface.

    1. On the enigma system, add the router entry to the /etc/hostname.hme1 file.


      192.168.116.16 router

    2. On the partym system, add the router entry to the /etc/hostname.hme1 file.


      192.168.13.213 router

    IP forwarding means that packets that arrive from somewhere else can be forwarded. IP forwarding also means that packets that leave this interface might have originated somewhere else. To successfully forward a packet, both the receiving interface and the transmitting interface must have IP forwarding turned on.

    Because the hme1 interface is inside the intranet, IP forwarding must be turned on for hme1. Because ip.tun0 connects the two systems through the Internet, IP forwarding must be turned on for ip.tun0.

    The hme0 interface has its IP forwarding turned off to prevent an outside adversary from injecting packets into the protected intranet. The outside refers to the Internet.

  11. Ensure that the routing protocols do not advertise the default route within the intranet.

    1. On the enigma system, add the private flag to the /etc/hostname.hme0 file.


      10.16.16.6 private

    2. On the partym system, add the private flag to the /etc/hostname.hme0 file.


      10.1.3.3 private

    Even if hme0 has IP forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the intranet. By setting the interface's private flag, these advertisements are prevented.

  12. Manually add a default route over the hme0 interface.

    The default route must be a router with direct access to the Internet.

    1. On the enigma system, add the following route:


      # route add default 192.168.116.4

    2. On the partym system, add the following route:


      # route add default 192.168.13.5

      Even though the hme0 interface is not part of the intranet, hme0 does need to reach across the Internet to its peer system. To find its peer, hme0 needs information about Internet routing. The VPN system appears to be a host, rather than a router, to the rest of the Internet. Therefore, you can use a default router or run the router discovery protocol to find a peer system. For more information, see the route(1M) and in.routed(1M) man pages.

  13. To complete the procedure, go to Step 22 to run a routing protocol.

  14. Configure the tunnel, ip.tun0.

    Note –

    The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

    Use ifconfig commands to create the point-to-point interface:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. On the enigma system, type the following commands:


      # 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

    2. On the partym system, type the following commands:


      # 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

  15. Protect the tunnel with the IPsec policy that you created.


    # ipsecconf

  16. Bring up the router for the tunnel.


    # ifconfig ip.tun0 router up

  17. Turn on IP forwarding for the hme1 interface.


    # ifconfig hme1 router

    IP forwarding means that packets that arrive from somewhere else can be forwarded. IP forwarding also means that packets that leave this interface might have originated somewhere else. To successfully forward a packet, both the receiving interface and the transmitting interface must have IP forwarding turned on.

    Because the hme1 interface is inside the intranet, IP forwarding must be turned on for hme1. Because ip.tun0 connects the two systems through the Internet, IP forwarding must be turned on for ip.tun0.

    The hme0 interface has its IP forwarding turned off to prevent an outside adversary from injecting packets into the protected intranet. The outside refers to the Internet.

  18. Ensure that routing protocols do not advertise the default route within the intranet.


    # ifconfig hme0 private

    Even if hme0 has IP forwarding turned off, a routing protocol implementation might still advertise the interface. For example, the in.routed protocol might still advertise that hme0 is available to forward packets to its peers inside the intranet. By setting the interface's private flag, these advertisements are prevented.

  19. Manually add a default route over hme0.

    The default route must be a router with direct access to the Internet.

    1. On the enigma system, add the following route:


      # route add default 192.168.116.4

    2. On the partym system, add the following route:


      # route add default 192.168.13.5

      Even though the hme0 interface is not part of the intranet, hme0 does need to reach across the Internet to its peer system. To find its peer, hme0 needs information about Internet routing. The VPN system appears to be a host, rather than a router, to the rest of the Internet. Therefore, you can use a default router or run the router discovery protocol to find a peer system. For more information, see the route(1M) and in.routed(1M) man pages.

  20. Ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname.ip.tun0 file.


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. On the enigma system, add the following entry to the hostname.ip.tun0 file:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. On the partym system, add the following entry to the hostname.ip.tun0 file:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  21. Configure the interface files to pass the correct parameters to the routing daemon.

    1. On the enigma system, modify the /etc/hostname.interface files.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. On the partym system, modify the /etc/hostname.interface files.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Run a routing protocol.


    # routeadm -e ipv4-routing
# routeadm -u

    You might need to configure the routing protocol before running the routing protocol. For more information, see Routing Protocols in Oracle Solaris. For a procedure, see How to Configure an IPv4 Router.

Example 20–10 Creating Temporary Tunnels When Testing

In this example, the administrator tests tunnel creation on a Solaris 10 4/09 system. Later, the administrator will use the procedure How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 to make the tunnels permanent. During testing, the administrator performs the following series of steps on the systems system1 and system2:

Example 20–11 Creating a Tunnel to an Earlier Version of a Solaris System by Using the Command Line

In the Solaris 10 7/07 release, the syntax of the ifconfig command was simplified. In this example, the administrator tests tunnel creation to a system that is running a version of Solaris prior to the Solaris 10 7/07 release. By using the original syntax of the ifconfig command, the administrator can use identical commands on the two communicating systems. Later, the administrator will use How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4 to make the tunnels permanent.

During testing, the administrator performs the following steps on the systems system1 and system2:

Example 20–12 Requiring IPsec Policy on All Systems on a LAN

In this example, the administrator comments out the bypass policy that was configured in Step 4, thereby strengthening the protection. With this policy configuration, each system on the LAN must activate IPsec to communicate with the router.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}
Example 20–13 Using IPsec to Protect Telnet Traffic Differently From SMTP Traffic

In this example, the first rule protects telnet traffic on port 23 with Blowfish and SHA-1. The second rule protects SMTP traffic on port 25 with AES and MD5.


{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}
Example 20–14 Using an IPsec Tunnel in Tunnel Mode to Protect a Subnet Differently From Other Network Traffic

The following tunnel configuration protects all traffic from subnet 10.1.3.0/24 across the tunnel:


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

The following tunnel configurations protect traffic from subnet 10.1.3.0/24 to different subnets across the tunnel. Subnets that begin with 10.2.x.x are across the tunnel.


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

ProcedureHow to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv6

To set up a VPN on an IPv6 network, you follow the same steps as for an IPv4 network. However, the syntax of the commands is slightly different. For a fuller description of the reasons for running particular commands, see the corresponding steps in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

Note –

Perform the steps in this procedure on both systems.

This procedure uses the following configuration parameters.

Parameter 

Europe 

California 

System name 

 

enigma
 

partym

System intranet interface 

 

hme1
 

hme1

System Internet interface 

 

hme0
 

hme0

System intranet address 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

System Internet address 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Name of Internet router 

 

router-E
 

router-C

Address of Internet router 

 

2001::aaaa:0:4
 

2001::eeee:0:1

Tunnel name 

 

ip6.tun0
 

ip6.tun0

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Control the flow of packets before configuring IPsec.

    For the effects of these commands, see Step 2 in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

    1. Ensure that IP forwarding and IP dynamic routing are disabled.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Caution – Caution –

      The value of ip6_strict_dst_multihoming reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

    3. Disable most network services, and possibly all network services.

      Note –

      If your system was installed with the “limited” SMF profile, then you can skip this step. Network services, with the exception of Solaris Secure Shell, are disabled.

      The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

      Choose one of the following options:

      • If you are running the Solaris 10 11/06 release or a later release, run the “limited” SMF profile.


        # netservices limited

      • Otherwise, individually disable network services.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. Verify that most network services are disabled.

      Verify that loopback mounts and the ssh service are running.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
...
online         Aug_09   svc:/network/ssh:default

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy for the VPN.

    Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN.

    1. On the enigma system, type the following entry into the ipsecinit.conf file:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. On the partym system, type the following entry into the ipsecinit.conf file:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Optional) Verify the syntax of the IPsec policy file.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:

    • Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.

    • If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

  7. Configure the tunnel, ip6.tun0, in the /etc/hostname.ip6.tun0 file.

    1. On the enigma system, add the following entry to the hostname.ip6.tun0 file:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. On the partym system, add the following entry to the hostname.ip6.tun0 file:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. Protect the tunnel with the IPsec policy that you created.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. To read the contents of the tunnel configuration file into the kernel, restart the network services.


    # svcadm restart svc:/network/initial:default

  10. Turn on IP forwarding for the hme1 interface.

    1. On the enigma system, add the router entry to the /etc/hostname6.hme1 file.


      2001::aaaa:6666:6666 inet6 router

    2. On the partym system, add the router entry to the /etc/hostname6.hme1 file.


      2001::eeee:3333:3333 inet6 router

  11. Ensure that routing protocols do not advertise the default route within the intranet.

    1. On the enigma system, add the private flag to the /etc/hostname6.hme0 file.


      6000:6666::aaaa:1116 inet6 private

    2. On the partym system, add the private flag to the /etc/hostname6.hme0 file.


      6000:3333::eeee:1113 inet6 private

  12. Manually add a default route over hme0.

    1. On the enigma system, add the following route:


      # route add -inet6 default 2001::aaaa:0:4

    2. On the partym system, add the following route:


      # route add -inet6 default 2001::eeee:0:1

  13. To complete the procedure, go to Step 22 to run a routing protocol.

  14. Configure a secure tunnel, ip6.tun0.

    Note –

    The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

    1. On the enigma system, type the following commands:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. On the partym system, type the following commands:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. Protect the tunnel with the IPsec policy that you created.


    # ipsecconf

  16. Bring up the router for the tunnel.


    # ifconfig ip6.tun0 router up

  17. On each system, turn on IP forwarding for the hme1 interface. 


    # ifconfig hme1 router

  18. Ensure that routing protocols do not advertise the default route within the intranet.


    # ifconfig hme0 private

  19. Manually add a default route over hme0.

    The default route must be a router with direct access to the Internet.

    1. On the enigma system, add the following route:


      # route add -inet6 default 2001::aaaa:0:4

    2. On the partym system, add the following route:


      # route add -inet6 default 2001::eeee:0:1

  20. Ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname6.ip6.tun0 file.

    The entry replicates the parameters that were passed to the ifconfig command in Step 14.

    1. On the enigma system, add the following entry to the hostname6.ip6.tun0 file:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666  tdst 2001::eeee:3333:3333 router up

    2. On the partym system, add the following entry to the hostname6.ip6.tun0 file:


      6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. On each system, configure the interface files to pass the correct parameters to the routing daemon.

    1. On the enigma system, modify the /etc/hostname6.interface files.


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. On the partym system, modify the /etc/hostname6.interface files.


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## partym
2001::eeee:3333:3333 inet6 router

  22. Run a routing protocol.


    # routeadm -e ipv6-routing
# routeadm -u

    You might need to configure the routing protocol before running the routing protocol. For more information, see Routing Protocols in Oracle Solaris. For a procedure, see Configuring an IPv6 Router.

ProcedureHow to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4

In transport mode, the outer header determines the IPsec policy that protects the inner IP packet.

This procedure extends the procedure How to Secure Traffic Between Two Systems With IPsec. In addition to connecting two systems, you are connecting two intranets that connect to these two systems. The systems in this procedure function as gateways.

This procedure uses the setup that is described in Description of the Network Topology for the IPsec Tasks to Protect a VPN. For a fuller description of the reasons for running particular commands, see the corresponding steps in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

Note –

Perform the steps in this procedure on both systems.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Control the flow of packets before configuring IPsec.

    1. Ensure that IP forwarding and IP dynamic routing are disabled.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip_strict_dst_multihoming 1
      Caution – Caution –

      The value of ip_strict_dst_multihoming reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

    3. Disable most network services, and possibly all network services.

      Note –

      If your system was installed with the “limited” SMF profile, then you can skip this step. Network services, with the exception of Solaris Secure Shell, are disabled.

      The disabling of network services prevents IP packets from doing any harm to the system. For example, an SNMP daemon, a telnet connection, or an rlogin connection could be exploited.

      Choose one of the following options:

      • If you are running the Solaris 10 11/06 release or a later release, run the “limited” SMF profile.


        # netservices limited

      • Otherwise, individually disable network services.


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. Verify that most network services are disabled.

      Verify that loopback mounts and the ssh service are running.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy.

    Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN. To strengthen the policy, see Example 20–15.

    1. On the enigma system, type the following entry into the ipsecinit.conf file:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. On the partym system, type the following entry into the ipsecinit.conf file:


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (Optional) Verify the syntax of the IPsec policy file.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:

    • Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.

    • If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

  7. Configure the tunnel, ip.tun0, in the /etc/hostname.ip.tun0 file.

    1. On the enigma system, add the following entry to the hostname.ip.tun0 file:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. On the partym system, add the following entry to the hostname.ip.tun0 file:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. Protect the tunnel with the IPsec policy that you created.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. To read the contents of the hostname.ip.tun0 file into the kernel, restartRestart the network services.


    # svcadm restart svc:/network/initial:default

  10. Turn on IP forwarding for the hme1 interface.

    1. On the enigma system, add the router entry to the /etc/hostname.hme1 file.


      192.168.116.16 router

    2. On the partym system, add the router entry to the /etc/hostname.hme1 file.


      192.168.13.213 router

  11. Ensure that routing protocols do not advertise the default route within the intranet.

    1. On the enigma system, add the private flag to the /etc/hostname.hme0 file.


      10.16.16.6 private

    2. On the partym system, add the private flag to the /etc/hostname.hme0 file.


      10.1.3.3 private

  12. Manually add a default route over hme0.

    1. On the enigma system, add the following route:


      # route add default 192.168.116.4

    2. On the partym system, add the following route:


      # route add default 192.168.13.5

  13. To complete the procedure, go to Step 22 to run a routing protocol.

  14. Configure the tunnel, ip.tun0.

    Note –

    The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

    Use ifconfig commands to create the point-to-point interface:


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. On the enigma system, type the following commands:


      # 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

    2. On the partym system, type the following commands:


      # 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

  15. Protect the tunnel with the IPsec policy that you created.


    # ipsecconf

  16. Bring up the router for the tunnel.


    # ifconfig ip.tun0 router up

  17. Turn on IP forwarding for the hme1 interface.


    # ifconfig hme1 router

  18. Ensure that routing protocols do not advertise the default route within the intranet.


    # ifconfig hme0 private

  19. Manually add a default route over hme0.

    The default route must be a router with direct access to the Internet.


    # route add default router-on-hme0-subnet

    1. On the enigma system, add the following route:


      # route add default 192.168.116.4

    2. On the partym system, add the following route:


      # route add default 192.168.13.5

  20. Ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname.ip.tun0 file.


    system1-point system2-point tsrc system1-taddr \
tdst system2-taddr encr_algs aes encr_auth_algs sha1 router up

    1. On the enigma system, add the following entry to the hostname.ip.tun0 file:


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 router up

    2. On the partym system, add the following entry to the hostname.ip.tun0 file:


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \
tdst 192.168.116.16 router up

  21. Configure the interface files to pass the correct parameters to the routing daemon.

    1. On the enigma system, modify the /etc/hostname.interface files.


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. On the partym system, modify the /etc/hostname.interface files.


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. Run a routing protocol.


    # routeadm -e ipv4-routing
# routeadm -u
Example 20–15 Requiring IPsec Policy on All Systems in Transport Mode

In this example, the administrator comments out the bypass policy that was configured in Step 4, thereby strengthening the protection. With this policy configuration, each system on the LAN must activate IPsec to communicate with the router.


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}
Example 20–16 Using Deprecated Syntax to Configure an IPsec Tunnel in Transport Mode

In this example, the administrator is connecting a Solaris 10 7/07 system with a system that is running the Solaris 10 release. Therefore, the administrator uses Solaris 10 syntax in the configuration file and includes the IPsec algorithms in the ifconfig command.

The administrator follows the procedure How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv4 with the following changes in syntax.

ProcedureHow to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6

To set up a VPN on an IPv6 network, you follow the same steps as for an IPv4 network. However, the syntax of the commands is slightly different. For a fuller description of the reasons for running particular commands, see the corresponding steps in How to Protect a VPN With an IPsec Tunnel in Tunnel Mode Over IPv4.

Note –

Perform the steps in this procedure on both systems.

This procedure uses the following configuration parameters.

Parameter 

Europe 

California 

System name 

 

enigma
 

partym

System intranet interface 

 

hme1
 

hme1

System Internet interface 

 

hme0
 

hme0

System intranet address 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

System Internet address 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

Name of Internet router 

 

router-E
 

router-C

Address of Internet router 

 

2001::aaaa:0:4
 

2001::eeee:0:1

Tunnel name 

 

ip6.tun0
 

ip6.tun0

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Control the flow of packets before configuring IPsec.

    1. Ensure that IP forwarding and IP dynamic routing are disabled.


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      If IP forwarding and IP dynamic routing are enabled, you can disable them by typing:


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. Turn on IP strict destination multihoming.


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      Caution – Caution –

      The value of ip6_strict_dst_multihoming reverts to the default when the system is booted. To make the changed value persistent, see How to Prevent IP Spoofing.

    3. Verify that most network services are disabled.

      Verify that loopback mounts and the ssh service are running.


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. Add a pair of SAs between the two systems.

    Choose one of the following options:

  4. Add IPsec policy.

    Edit the /etc/inet/ipsecinit.conf file to add the IPsec policy for the VPN.

    1. On the enigma system, type the following entry into the ipsecinit.conf file:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

    2. On the partym system, type the following entry into the ipsecinit.conf file:


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

  5. (Optional) Verify the syntax of the IPsec policy file.


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. To configure the tunnel and protect it with IPsec, follow the steps according to the Solaris release:

    • Starting in the Solaris 10 4/09 release, follow the steps from Step 7 to Step 13, then run the routing protocol in Step 22.

    • If you are running a release prior to the Solaris 10 4/09 release, follow the steps from Step 14 to Step 22.

  7. Configure the tunnel, ip6.tun0, in the /etc/hostname.ip6.tun0 file.

    1. On the enigma system, add the following entry to the hostname.ip6.tun0 file:


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. On the partym system, add the following entry to the hostname.ip6.tun0 file:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. Protect the tunnel with the IPsec policy that you created.


    # svcadm refresh svc:/network/ipsec/policy:default

  9. To read the contents of the hostname.ip6.tun0 file into the kernel, restart the network services.


    # svcadm restart svc:/network/initial:default

  10. Turn on IP forwarding for the hme1 interface.

    1. On the enigma system, add the router entry to the /etc/hostname6.hme1 file.


      2001::aaaa:6666:6666 inet6 router

    2. On the partym system, add the router entry to the /etc/hostname6.hme1 file.


      2001::eeee:3333:3333 inet6 router

  11. Ensure that routing protocols do not advertise the default route within the intranet.

    1. On the enigma system, add the private flag to the /etc/hostname6.hme0 file.


      6000:6666::aaaa:1116 inet6 private

    2. On the partym system, add the private flag to the /etc/hostname6.hme0 file.


      6000:3333::eeee:1113 inet6 private

  12. Manually add a default route over hme0.

    1. On the enigma system, add the following route:


      # route add -inet6 default 2001::aaaa:0:4

    2. On the partym system, add the following route:


      # route add -inet6 default 2001::eeee:0:1

  13. To complete the procedure, go to Step 22 to run a routing protocol.

  14. Configure a secure tunnel, ip6.tun0.

    Note –

    The following steps configure a tunnel on a system that is running a release prior to the Solaris 10 4/09 release.

    1. On the enigma system, type the following commands:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. On the partym system, type the following commands:


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6  6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. Protect the tunnel with the IPsec policy that you created.


    # ipsecconf

  16. Bring up the router for the tunnel.


    # ifconfig ip6.tun0 router up

  17. Turn on IP forwarding for the hme1 interface. 


    # ifconfig hme1 router

  18. Ensure that routing protocols do not advertise the default route within the intranet.


    # ifconfig hme0 private

  19. On each system, manually add a default route over hme0.

    The default route must be a router with direct access to the Internet.

    1. On the enigma system, add the following route:


      # route add -inet6 default 2001::aaaa:0:4

    2. On the partym system, add the following route:


      # route add -inet6 default 2001::eeee:0:1

  20. On each system, ensure that the VPN starts after a reboot by adding an entry to the /etc/hostname6.ip6.tun0 file.

    The entry replicates the parameters that were passed to the ifconfig command in Step 14.

    1. On the enigma system, add the following entry to the hostname6.ip6.tun0 file:


      6000:6666::aaaa:1116  6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333  router up

    2. On the partym system, add the following entry to the hostname6.ip6.tun0 file:


      6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. Configure the interface files to pass the correct parameters to the routing daemon.

    1. On the enigma system, modify the /etc/hostname6.interface files.


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. On the partym system, modify the /etc/hostname6.interface files.


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## 
partym2001::eeee:3333:3333 inet6 router

  22. Run a routing protocol.


    # routeadm -e ipv6-routing
# routeadm -u
Example 20–17 Using Deprecated Syntax to Configure IPsec in Transport Mode Over IPv6

In this example, the administrator is connecting a Solaris 10 7/07 system with a system that is running the Solaris 10 release. Therefore, the administrator uses Solaris 10 syntax in the configuration file and includes the IPsec algorithms in the ifconfig command.

The administrator follows the procedure How to Protect a VPN With an IPsec Tunnel in Transport Mode Over IPv6 with the following changes in syntax.

ProcedureHow to Prevent IP Spoofing

To prevent the system from forwarding packets to another interface without trying to decrypt them, the system needs to check for IP spoofing. One method of prevention is to set the IP strict destination multihoming parameter by using the ndd command. When this parameter is set in an SMF manifest, the parameter is set when the system reboots.

Note –

Perform the steps in this procedure on both systems.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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.

  2. Create the site-specific SMF manifest to check for IP spoofing.

    Use the following sample script, /var/svc/manifest/site/spoof_check.xml.

    <?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='Custom:ip_spoof_checking'>

<!--    This is a custom smf(5) manifest for this system. Place this
        file in /var/svc/manifest/site, the directory for local
        system customizations. The exec method uses an unstable
        interface to provide a degree of protection against IP
        spoofing attacks when this system is acting as a router.

        IP spoof protection can also be achieved by using ipfilter(5).
        If ipfilter is configured, this service can be disabled.

        Note: Unstable interfaces might be removed in later
        releases.  See attributes(5).
-->

<service
        name='site/ip_spoofcheck'
        type='service'
        version='1'>

        <create_default_instance enabled='false' />
        <single_instance />

        <!--    Don't enable spoof protection until the
                network is up.
        -->
        <dependency
                name='basic_network'
                grouping='require_all'
                restart_on='none'
                type='service'>
        <service_fmri value='svc:/milestone/network' />
        </dependency>

        <exec_method
                type='method'
                name='start'
                exec='/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1'
<!--    
     For an IPv6 network, use the IPv6 version of this command, as in:
                exec='/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1
-->
                timeout_seconds='60'
        />

        <exec_method
                type='method'
                name='stop'
                exec=':true'
                timeout_seconds='3'
        />

        <property_group name='startd' type='framework'>
                <propval
                        name='duration'
                        type='astring'
                        value='transient'
                />
        </property_group>

        <stability value='Unstable' />

</service>
</service_bundle>

  3. Import this manifest into the SMF repository.


    # svccfg import /var/svc/manifest/site/spoof_check.xml

  4. Enable the ip_spoofcheck service.

    Use the name that is defined in the manifest, /site/ip_spoofcheck.


    # svcadm enable /site/ip_spoofcheck

  5. Verify that the ip_spoofcheck service is online.


    # svcs /site/ip_spoofcheck

Chapter 21 IP Security Architecture (Reference)

This chapter contains the following reference information:

For instructions on how to implement IPsec on your network, see Chapter 20, Configuring IPsec (Tasks). For an overview of IPsec, see Chapter 19, IP Security Architecture (Overview).

IPsec Service Management Facility

The service management facility (SMF) provides the following services for IPsec:

For information about SMF, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also see the smf(5), svcadm(1M), and svccfg(1M) man pages.

ipsecconf Command

You use the ipsecconf command to configure the IPsec policy for a host. When you run the command to configure the policy, the system creates the IPsec policy entries in the kernel. The system uses these entries to check the policy on all inbound and outbound IP datagrams. Forwarded datagrams are not subjected to policy checks that are added by using this command. The ipsecconf command also configures the security policy database (SPD).

You must become superuser or assume an equivalent role to invoke the ipsecconf command. The command accepts entries that protect traffic in both directions. The command also accepts entries that protect traffic in only one direction.

Policy entries with a format of local address and remote address can protect traffic in both directions with a single policy entry. For example, entries that contain the patterns laddr host1 and raddr host2 protect traffic in both directions, if no direction is specified for the named host. Thus, you need only one policy entry for each host.

Policy entries with a format of source address to destination address protect traffic in only one direction. For example, a policy entry of the pattern saddr host1 daddr host2 protects inbound traffic or outbound traffic, not both directions. Thus, to protect traffic in both directions, you need to pass the ipsecconf command another entry, as in saddr host2 daddr host1.

To ensure that the IPsec policy is active when the machine boots, you can create an IPsec policy file, /etc/inet/ipsecinit.conf. This file is read when the network services are started. For instructions on how to create an IPsec policy file, see Protecting Traffic With IPsec (Task Map).

Starting in the Solaris 10 4/09 release, with the -c option, the ipsecconf command checks the syntax of the IPsec policy file that you provide as an argument.

Policy entries that are added by the ipsecconf command are not persistent over a system reboot. To ensure that the IPsec policy is active when the system boots, add the policy entries to the /etc/inet/ipsecinit.conf file. In the current release, refresh or enable the policy service. In a release prior to the Solaris 10 4/09 release, reboot or use the ipsecconf command. For examples, see Protecting Traffic With IPsec (Task Map).

ipsecinit.conf File

To invoke IPsec security policies when you start the Solaris Operating System (Solaris OS), 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 policies are configured, you can use the ipsecconf command to view or modify the existing configuration. Starting in the Solaris 10 4/09 release, you refresh the policy service to modify the existing configuration.

Sample ipsecinit.conf File

The 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:


#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#	 {lport 23 dir in} drop {}
#	 {lport 23 dir out} drop {}
# will disallow any remote system from telnetting in.
#
# If you are using IPv6, it may be useful to bypass neighbor discovery
# to allow in.iked to work properly with on-link neighbors. To do that,
# add the following lines:
#
#        {ulp ipv6-icmp type 133-137 dir both } pass { }
#
# This will allow neighbor discovery to work normally.

Security Considerations for ipsecinit.conf and ipsecconf

Use extreme caution if transmitting a copy of the ipsecinit.conf file over a network. An adversary can read a network-mounted file as the file is being read. If, for example, the /etc/inet/ipsecinit.conf file is accessed or is copied from an NFS-mounted file system, an adversary can change the policy that is contained in the file.

Ensure that you set up IPsec policies before starting any communications, because existing connections might be affected by the addition of new policy entries. Similarly, do not change policies in the middle of a communication.

Specifically, IPsec policy cannot be changed for SCTP, TCP, or UDP sockets on which a connect() or accept() function call has been issued. 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.

Protect your naming system. If the following two conditions are met, then your host names are no longer trustworthy:

Security weaknesses often arise from the misapplication of tools, not from the actual tools. You should be cautious when using the ipsecconf command. Use a console or other hard-connected TTY for the safest mode of operation.

ipsecalgs Command

The Solaris cryptographic framework provides authentication and encryption algorithms to IPsec. The ipsecalgs command can list the algorithms that each IPsec protocol supports. The ipsecalgs configuration is stored in the /etc/inet/ipsecalgs file. Typically, this file does not need to be modified. However, if the file needs to be modified, use the ipsecalgs command. The file must never be edited directly. In the current release, the supported algorithms are synchronized with the kernel at system boot by the svc:/network/ipsec/ipsecalgs:default service.

The valid IPsec protocols and algorithms are described by the ISAKMP domain of interpretation (DOI), which is covered by RFC 2407. In a general sense, a DOI defines data formats, network traffic exchange types, and conventions for naming security-relevant information. Security policies, cryptographic algorithms, and cryptographic modes are examples of security-relevant information.

Specifically, the ISAKMP DOI defines the naming and numbering conventions for the valid IPsec algorithms and for their protocols, PROTO_IPSEC_AH and PROTO_IPSEC_ESP. Each algorithm is associated with exactly one protocol. These ISAKMP DOI definitions are in the /etc/inet/ipsecalgs file. The algorithm and protocol numbers are defined by the Internet Assigned Numbers Authority (IANA). The ipsecalgs command makes the list of algorithms for IPsec extensible.

For more information about the algorithms, refer to the ipsecalgs(1M) man page. For more information on the Solaris cryptographic framework, see Chapter 13, Solaris Cryptographic Framework (Overview), in System Administration Guide: Security Services.

Security Associations Database for IPsec

Information on key material for IPsec security services is maintained in a security associations database (SADB). Security associations (SAs) protect inbound packets and outbound packets. The SADBs are maintained by a user process, or possibly multiple cooperating processes, that send messages over a special kind of socket. This method of maintaining SADBs is analogous to the method that is described in the route(7P) man page. Only superuser or a user who has assumed an equivalent role can access the database.

The in.iked daemon and the ipseckey command use the PF_KEY socket interface to maintain SADBs. For more information on how SADBs handle requests and messages, see the pf_key(7P) man page.

Utilities for Key Generation in IPsec

The IKE protocol provides automatic key management for IPv4 and IPv6 addresses. See Chapter 23, Configuring IKE (Tasks) for instructions on how to set up IKE. The manual keying utility is the ipseckey command, which is described in the ipseckey(1M) man page.

You use the ipseckey command to manually populate the security associations database (SADB). Typically, manual SA generation is used when IKE is unavailable for some reason. However, if the SPI values are unique, manual SA generation and IKE can be used at the same time.

The ipseckey command can be used to view all SAs that are known to the system, whether the keys were added manually or by IKE. Starting in the Solaris 10 4/09 release, with the -c option, the ipseckey command checks the syntax of the keys file that you provide as an argument.

IPsec SAs that are added by the ipseckey command are not persistent over system reboot. In the current release, to enable manually added SAs at system boot, add entries to the /etc/inet/secret/ipseckeys file, then enable the svc:/network/ipsec/manual-key:default service. For the procedure, see How to Manually Create IPsec Security Associations.

While the ipseckey command has only a limited number of general options, the command supports a rich command language. You can specify that requests be delivered by means of a programmatic interface specific for manual keying. For additional information, see the pf_key(7P) man page.

Security Considerations for ipseckey

The ipseckey command enables superuser or a role with the Network Security or Network IPsec Management rights profile to enter sensitive cryptographic keying information. If an adversary gains access to this information, the adversary can compromise the security of IPsec traffic.

You should consider the following issues when you handle keying material and use the ipseckey command:

Security weaknesses often arise from the misapplication of tools, not from the actual tools. You should be cautious when using the ipseckey command. Use a console or other hard-connected TTY for the safest mode of operation.

IPsec Extensions to Other Utilities

The ifconfig command has options to manage the IPsec policy on a tunnel interface. The snoop command can parse AH and ESP headers.

ifconfig Command and IPsec

In the Solaris 10, Solaris 10 7/05, Solaris 10 1/06, and Solaris 10 11/06 releases: To support IPsec, the following security options are available from the ifconfig command. These security options are handled by the ipsecconf command in the Solaris 10 7/07 release.

You must specify all IPsec security options for a tunnel in one invocation. For example, if you are using only ESP to protect traffic, you would configure the tunnel, ip.tun0, once with both security options, as in:


# ifconfig ip.tun0 encr_algs aes encr_auth_algs md5

Similarly, an ipsecinit.conf entry would configure the tunnel once with both security options, as in:


# WAN traffic uses ESP with AES and MD5.
   {} ipsec {encr_algs aes encr_auth_algs md5}

auth_algs Security Option

This option enables IPsec AH for a tunnel with a specified authentication algorithm. The auth_algs option has the following format:


auth_algs authentication-algorithm

For the algorithm, you can specify either a number or an algorithm name, including the parameter any, to express no specific algorithm preference. To disable tunnel security, specify the following option:


auth_algs none

For a list of available authentication algorithms, run the ipsecalgs command.

Note –

The auth_algs option cannot work with NAT-Traversal. For more information, see IPsec and NAT Traversal.

encr_auth_algs Security Option

This option enables IPsec ESP for a tunnel with a specified authentication algorithm. The encr_auth_algs option has the following format:


encr_auth_algs authentication-algorithm

For the algorithm, you can specify either a number or an algorithm name, including the parameter any, to express no specific algorithm preference. If you specify an ESP encryption algorithm, but you do not specify the authentication algorithm, the ESP authentication algorithm value defaults to the parameter any.

For a list of available authentication algorithms, run the ipsecalgs command.

encr_algs Security Option

This option enables IPsec ESP for a tunnel with a specified encryption algorithm. The encr_algs option has the following format:


encr_algs encryption-algorithm

For the algorithm, you can specify either a number or an algorithm name. To disable tunnel security, specify the following option:


encr_algs none

If you specify an ESP authentication algorithm, but not an encryption algorithm, ESP's encryption value defaults to the parameter null.

For a list of available encryption algorithms, run the ipsecalgs command.

snoop Command and IPsec

The snoop command can parse AH and ESP headers. Because ESP encrypts its data, the snoop command cannot see encrypted headers that are protected by ESP. AH does not encrypt data. Therefore, traffic that is protected by AH can be inspected with the snoop command. The -V option to the command shows when AH is in use on a packet. For more details, see the snoop(1M) man page.

For a sample of verbose snoop output on a protected packet, see How to Verify That Packets Are Protected With IPsec.

Chapter 22 Internet Key Exchange (Overview)

Internet Key Exchange (IKE) automates key management for IPsec. This chapter contains the following information about IKE:

For instructions on implementing IKE, see Chapter 23, Configuring IKE (Tasks). For reference information, see Chapter 24, Internet Key Exchange (Reference). For information about IPsec, see Chapter 19, IP Security Architecture (Overview).

What's New in IKE?

Solaris 10 4/09: Starting in this release, the Service Management Facility (SMF) manages IKE as a service. By default, the svc:/network/ipsec/ike:default service is disabled. Also in this release, the Network IPsec Management rights profile is provided for administering IPsec and IKE.

Solaris 10 7/07: Starting in this release, IKE can use the AES algorithm and can be configured in the global zone for use in non-global zones.

Key Management With IKE

The management of keying material for IPsec security associations (SAs) is called key management. Automatic key management requires a secure channel of communication for the creation, authentication, and exchange of keys. The Solaris Operating System uses Internet Key Exchange (IKE) to automate key management. IKE easily scales to provide a secure channel for a large volume of traffic. IPsec SAs on IPv4 and IPv6 packets can take advantage of IKE.

When IKE is used on a system with a Sun Crypto Accelerator 1000 board or a Sun Crypto Accelerator 4000 or Sun Crypto Accelerator 6000 board, the public key operations can be offloaded to the accelerator. Operating system resources are not used for public key operations. When IKE is used on a system with a Sun Crypto Accelerator 4000 or Sun Crypto Accelerator 6000 board, the certificates, public keys, and private keys can be stored on the board. Key storage that is off the system provides an additional layer of protection.

IKE Key Negotiation

The IKE daemon, in.iked, negotiates and authenticates keying material for SAs in a protected manner. The daemon uses random seeds for keys from internal functions provided by the Solaris Operating System. IKE provides perfect forward secrecy (PFS). In PFS, the keys that protect data transmission are not used to derive additional keys. Also, seeds used to create data transmission keys are not reused. See the in.iked(1M) man page.

When the IKE daemon discovers a remote system's public encryption key, the local system can then use that key. The system encrypts messages by using the remote system's public key. The messages can be read only by that remote system. The IKE daemon performs its job in two phases. The phases are called exchanges.

IKE Key Terminology

The following table lists terms that are used in key negotiation, provides their commonly used acronyms, and gives a definition and use for each term.

Table 22–1 Key Negotiation Terms, Acronyms, and Uses

Key Negotiation Term 

Acronym 

Definition and Use 

Key exchange 

 

The process of generating keys for asymmetric cryptographic algorithms. The two main methods are RSA protocols and the Diffie-Hellman protocol. 

Diffie-Hellman protocol 

DH 

A key exchange protocol that involves key generation and key authentication. Often called authenticated key exchange.

RSA protocol 

RSA 

A key exchange protocol that involves key generation and key transport. The protocol is named for its three creators, Rivest, Shamir, and Adleman. 

Perfect forward secrecy

PFS 

Applies to authenticated key exchange only. PFS ensures that long-term secret material for keys does not compromise the secrecy of the exchanged keys from previous communications.  

In PFS, the key that is used to protect transmission of data is not used to derive additional keys. Also, the source of the key that is used to protect data transmission is never used to derive additional keys. 

Oakley method 

 

A method for establishing keys for Phase 2 in a secure manner. This protocol is analogous to the Diffie-Hellman method of key exchange. Similar to Diffie-Hellman, Oakley group key exchange involves key generation and key authentication. The Oakley method is used to negotiate PFS. 

IKE Phase 1 Exchange

The Phase 1 exchange is known as Main Mode. In the Phase 1 exchange, IKE uses public key encryption methods to authenticate itself with peer IKE entities. The result is an Internet Security Association and Key Management Protocol (ISAKMP) security association (SA). An ISAKMP SA is a secure channel for IKE to negotiate keying material for the IP datagrams. Unlike IPsec SAs, the ISAKMP SAs are bidirectional, so only one security association is needed.

How IKE negotiates keying material in the Phase 1 exchange is configurable. IKE reads the configuration information from the /etc/inet/ike/config file. Configuration information includes the following:

The two authentication methods are preshared keys and public key certificates. The public key certificates can be self-signed. Or, the certificates can be issued by a certificate authority (CA) from a public key infrastructure (PKI) organization. Organizations include beTrusted, Entrust, GeoTrust, RSA Security, and Verisign.

IKE Phase 2 Exchange

The Phase 2 exchange is known as Quick Mode. In the Phase 2 exchange, IKE creates and manages the IPsec SAs between systems that are running the IKE daemon. IKE uses the secure channel that was created in the Phase 1 exchange to protect the transmission of keying material. The IKE daemon creates the keys from a random number generator by using the /dev/random device. The daemon refreshes the keys at a configurable rate. The keying material is available to algorithms that are specified in the configuration file for IPsec policy, ipsecinit.conf.

IKE Configuration Choices

The /etc/inet/ike/config configuration file contains IKE policy entries. For two IKE daemons to authenticate each other, the entries must be valid. Also, keying material must be available. The entries in the configuration file determine the method for using the keying material to authenticate the Phase 1 exchange. The choices are preshared keys or public key certificates.

The entry auth_method preshared indicates that preshared keys are used. Values for auth_method other than preshared indicate that public key certificates are to be used. Public key certificates can be self-signed, or the certificates can be installed from a PKI organization. For more information, see the ike.config(4) man page.

IKE With Preshared Keys

Preshared keys are created by an administrator on one system. The keys are then shared out of band with administrators of remote systems. You should take care to create large random keys and to protect the file and the out-of-band transmission. The keys are placed in the /etc/inet/secret/ike.preshared file on each system. The ike.preshared file is for IKE as the ipseckeys file is for IPsec. Any compromise of the keys in the ike.preshared file compromises all keys that are derived from the keys in the file.

One system's preshared key must be identical to its remote system's key. The keys are tied to a particular IP address. Keys are most secure when one administrator controls the communicating systems. For more information, see the ike.preshared(4) man page.

IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Public keys use the Diffie-Hellman protocol (DH) for authenticating and negotiating keys. Public key certificates come in two flavors. The certificates can be self-signed, or the certificates can be certified by a certificate authority (CA).

Self-signed public key certificates are created by you, the administrator. The ikecert certlocal -ks command creates the private part of the public-private key pair for the system. You then get the self-signed certificate output in X.509 format from the remote system. The remote system's certificate is input to the ikecert certdb command for the public part of the key pair. The self-signed certificates reside in the /etc/inet/ike/publickeys directory on the communicating systems. When you use the -T option, the certificates reside on attached hardware.

Self-signed certificates are a halfway point between preshared keys and CAs. Unlike preshared keys, a self-signed certificate can be used on a mobile machine or on a system that might be renumbered. To self-sign a certificate for a system without a fixed number, use a DNS (www.example.org) or email (root@domain.org) alternative name.

Public keys can be delivered by a PKI or a CA organization. You install the public keys and their accompanying CAs in the /etc/inet/ike/publickeys directory. When you use the -T option, the certificates reside on attached hardware. Vendors also issue certificate revocation lists (CRLs). Along with installing the keys and CAs, you are responsible for installing the CRL in the /etc/inet/ike/crls directory.

CAs have the advantage of being certified by an outside organization, rather than by the site administrator. In a sense, CAs are notarized certificates. As with self-signed certificates, CAs can be used on a mobile machine or on a system that might be renumbered. Unlike self-signed certificates, CAs can very easily scale to protect a large number of communicating systems.

IKE and Hardware Acceleration

IKE algorithms are computationally expensive, particularly in the Phase 1 exchange. Systems that handle a large number of exchanges can use a Sun Crypto Accelerator 1000 board to handle the public key operations. The Sun Crypto Accelerator 6000 and Sun Crypto Accelerator 4000 boards can also be used to handle expensive Phase 1 computations.

For information on how to configure IKE to offload its computations to the accelerator board, see How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board. For information on how to store keys, see How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board, and the cryptoadm(1M) man page.

IKE and Hardware Storage

Public key certificates, private keys, and public keys can be stored on a Sun Crypto Accelerator 6000 or Sun Crypto Accelerator 4000 board. For RSA encryption, the Sun Crypto Accelerator 4000 board supports keys up to 2048 bits. For DSA encryption, the board supports keys up to 1024 bits. The Sun Crypto Accelerator 6000 board supports the SHA-512 and ECC algorithms.

For information on how to configure IKE to access the board, see How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board. For information on how to add certificates and public keys to the board, see How to Generate and Store Public Key Certificates on Hardware.

IKE Utilities and Files

The following table summarizes the configuration files for IKE policy, the storage locations for IKE keys, and the various commands and services that implement IKE. For more about services, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration.

Table 22–2 IKE Configuration Files, Key Storage Locations, Commands, and Services

File, Location, Command, or Service 

Description 

For More Information 

svc:/network/ipsec/ike

In the current release, the SMF service that manages IKE.

smf(5)

/usr/lib/inet/in.iked daemon

Internet Key Exchange (IKE) daemon. Activates automated key management. In the current release, the ike service enables this daemon. In earlier releases, the in.iked command is used.

in.iked(1M)

/usr/sbin/ikeadm command

IKE administration command for viewing and modifying the IKE policy.

ikeadm(1M)

/usr/sbin/ikecert command

Certificate database management command for manipulating local databases that hold public key certificates. The databases can also be stored on an attached Sun Crypto Accelerator 4000 board.

ikecert(1M)

/etc/inet/ike/config file

Default configuration file for the IKE policy in the /etc/inet directory. Contains the site's rules for matching inbound IKE requests and preparing outbound IKE requests.

In the current release, if this file exists, the in.iked daemon starts when the ike service is enabled. The location of this file can be changed by the svccfg command.

ike.config(4)

ike.preshared file

Preshared keys file in the /etc/inet/secret directory. Contains secret keying material for authentication in the Phase 1 exchange. Used when configuring IKE with preshared keys.

ike.preshared(4)

ike.privatekeys directory

Private keys directory in the /etc/inet/secret directory. Contains the private keys that are part of a public-private key pair.

ikecert(1M)

publickeys directory

Directory in the /etc/inet/ike directory that holds public keys and certificate files. Contains the public key part of a public-private key pair.

ikecert(1M)

crls directory

Directory in the /etc/inet/ike directory that holds revocation lists for public keys and certificate files.

ikecert(1M)

Sun Crypto Accelerator 1000 board 

Hardware that accelerates public key operations by offloading the operations from the operating system. 

ikecert(1M)

Sun Crypto Accelerator 4000 board 

Hardware that accelerates public key operations by offloading the operations from the operating system. The board also stores public keys, private keys, and public key certificates. 

ikecert(1M)

Changes to IKE for the Solaris 10 Release

Since the Solaris 9 release, IKE includes the following functionality:

Chapter 23 Configuring IKE (Tasks)

This chapter describes how to configure the Internet Key Exchange (IKE) for your systems. After IKE is configured, it automatically generates keying material for IPsec on your network. This chapter contains the following information:

For overview information about IKE, see Chapter 22, Internet Key Exchange (Overview). For reference information about IKE, see Chapter 24, Internet Key Exchange (Reference). For more procedures, see the Examples sections of the ikeadm(1M), ikecert(1M), and ike.config(4) man pages.

Configuring IKE (Task Map)

You can use preshared keys, self-signed certificates, and certificates from a Certificate Authority (CA) to authenticate IKE. A rule links the particular IKE authentication method with the end points that are being protected. Therefore, you can use one or all IKE authentication methods on a system. A pointer to a PKCS #11 library enables certificates to use an attached hardware accelerator.

After configuring IKE, complete the IPsec task that uses the IKE configuration. The following table refers you to task maps that focus on a specific IKE configuration.

Task 

Description 

For Instructions 

Configure IKE with preshared keys 

Protects communications between two systems by having the systems share a secret key. 

Configuring IKE With Preshared Keys (Task Map)

Configure IKE with public key certificates 

Protects communications with public key certificates. The certificates can be self-signed, or they can be vouched for by a PKI organization. 

Configuring IKE With Public Key Certificates (Task Map)

Cross a NAT boundary 

Configures IPsec and IKE to communicate with a mobile system 

Configuring IKE for Mobile Systems (Task Map)

Configure IKE to generate and store public key certificates on attached hardware 

Enables a Sun Crypto Accelerator 1000 board or a Sun Crypto Accelerator 4000 board to accelerate IKE operations. Also enables the Sun Crypto Accelerator 4000 board to store public key certificates. 

Configuring IKE to Find Attached Hardware (Task Map)

Tune Phase 1 key negotiation parameters 

Changes the timing of IKE key negotiations. 

Changing IKE Transmission Parameters (Task Map)

Configuring IKE With Preshared Keys (Task Map)

The following table points to procedures to configure and maintain IKE with preshared keys.

Task 

Description 

For Instructions 

Configure IKE with preshared keys 

Creates an IKE policy file and one key to be shared. 

How to Configure IKE With Preshared Keys

Refresh preshared keys on a running IKE system 

Adds fresh keying material for IKE on communicating systems. 

How to Refresh IKE Preshared Keys

Add preshared keys to a running IKE system 

Adds a new IKE policy entry and new keying material to a system that is currently enforcing IKE policy. 

How to Add an IKE Preshared Key for a New Policy Entry in ipsecinit.conf

Check that preshared keys are identical 

Displays the preshared keys on both systems to see that the keys are identical. 

How to Verify That IKE Preshared Keys Are Identical

Configuring IKE With Preshared Keys

Preshared keys is the simplest authentication method for IKE. If you are configuring two systems to use IKE, and you are the administrator for both of the systems, using preshared keys is a good choice. However, unlike public key certificates, preshared keys are tied to particular IP addresses. Preshared keys cannot be used with mobile systems or systems that might be renumbered. Also, when you use preshared keys, you cannot offload IKE computations to attached hardware.

ProcedureHow to Configure IKE With Preshared Keys

The IKE implementation offers algorithms whose keys vary in length. The key length that you choose is determined by site security. In general, longer keys provide more security than shorter keys.

These procedures use the system names enigma and partym. Substitute the names of your systems for the names enigma and partym.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. On each system, copy the file /etc/inet/ike/config.sample to the file /etc/inet/ike/config.

  3. Enter rules and global parameters in the ike/config file on each system.

    The rules and global parameters in this file should permit the IPsec policy in the system's ipsecinit.conf file to succeed. The following ike/config examples work with the ipsecinit.conf examples in How to Secure Traffic Between Two Systems With IPsec.

    1. For example, modify the /etc/inet/ike/config file on the enigma system:


      ### ike/config file on enigma, 192.168.116.16

## Global parameters
#
## Phase 1 transform defaults
p1_lifetime_secs 14400
p1_nonce_len 40
#
## Defaults that individual rules can override.
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2
#
## The rule to communicate with partym
#  Label must be unique
{ label "enigma-partym"
  local_addr 192.168.116.16
  remote_addr 192.168.13.213
  p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
  p2_pfs 5
}
      Note –

      All arguments to the auth_method parameter must be on the same line.

    2. Modify the /etc/inet/ike/config file on the partym system:


      ### ike/config file on partym, 192.168.13.213
## Global Parameters
#
p1_lifetime_secs 14400
p1_nonce_len 40
#
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2

## The rule to communicate with enigma
#  Label must be unique
{ label "partym-enigma"
  local_addr 192.168.13.213
  remote_addr 192.168.116.16
p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
p2_pfs 5
}

  4. On each system, verify the syntax of the file.


    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

  5. Generate random numbers for use as keying material.

    If your site has a random number generator, use that generator. On a Solaris system, you can use the od command. For example, the following command prints two lines of hexadecimal numbers:


    % od -X -A n /dev/random | head -2
         f47cb0f4 32e14480 951095f8 2b735ba8
         0a9467d0 8f92c880 68b6a40e 0efe067d

    For an explanation of the od command, see How to Generate Random Numbers on a Solaris System and the od(1) man page.

    Note –

    Other operating systems can require ASCII keying material. To generate the identical key in hexadecimal and ASCII formats, see Example 23–1.

  6. From the output of Step 5, construct one key.


    f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

    The authentication algorithm in this procedure is SHA–1, as shown in Step 3. The size of the hash, that is, the size of the authentication algorithm's output, determines the minimum recommended size of a preshared key. The output of the SHA–1 algorithm is 160 bits, or 40 characters. The example key is 56 characters long, which provides additional keying material for IKE to use.

  7. Create the file /etc/inet/secret/ike.preshared on each system.

    Put the preshared key in each file.

    1. For example, on the enigma system, the ike.preshared file would appear similar to the following:


      # ike.preshared on enigma, 192.168.116.16
#…
{ localidtype IP
	localid 192.168.116.16
	remoteidtype IP
	remoteid 192.168.13.213
	# enigma and partym's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}

    2. On the partym system, the ike.preshared file would appear similar to the following:


      # ike.preshared on partym, 192.168.13.213
#…
{ localidtype IP
	localid 192.168.13.213
	remoteidtype IP
	remoteid 192.168.116.16
	# partym and enigma's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}
    Note –

    The preshared keys on each system must be identical.

Example 23–1 Generating Identical Keying Material for Two Systems With Different Operating Systems

Solaris IPsec interoperates with other operating systems. If your system is communicating with a system that requires ASCII preshared keys, you need to generate one key in two formats, hexadecimal and ASCII.

In this example, the Solaris system administrator wants 56 characters of keying material. The administrator uses the following command to generate a hexadecimal key from an ASCII passphrase. The option -tx1 prints the bytes one at a time on all Solaris systems.


# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

By removing the offsets and concatenating the hexadecimal output, the hexadecimal key for the Solaris system is 7061706965726d616368652077697468206361736865777320616e64. The administrator places this value in the ike.preshared file on the Solaris system.


# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

On the system that requires ASCII preshared keys, the passphrase is the preshared key. The Solaris system administrator telephones the other administrator with the passphrase, papiermache with cashews and.

ProcedureHow to Refresh IKE Preshared Keys

This procedure assumes that you want to replace an existing preshared key at regular intervals.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Generate random numbers and construct a key of the appropriate length.

    For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a Solaris system that is communicating with an operating system that requires ASCII, see Example 23–1.

  3. Replace the current key with a new key.

    For example, on the hosts enigma and partym, you would replace the value of key in the /etc/inet/secret/ike.preshared file with a new number of the same length.

  4. Read the new key into the kernel.

    • Starting in the Solaris 10 4/09 release, refresh the ike service.


      # svcadm refresh ike

    • If you are running a release prior to the Solaris 10 4/09 release, kill and restart the in.iked daemon.

      1. Check the privilege level of the in.iked daemon.


        # /usr/sbin/ikeadm get priv
Current privilege level is 0x0, base privileges enabled

        You can change the keying material if the command returns a privilege level of 0x1 or 0x2. Level 0x0 does not permit operations to modify or view keying material. By default, the in.iked daemon runs at the 0x0 level of privilege.

      2. If the privilege level is 0x0, kill and restart the daemon.

        When the daemon restarts, it reads the new version of the ike.preshared file.


        # pkill in.iked
# /usr/lib/inet/in.iked

      3. If the privilege level is 0x1 or 0x2, read in the new version of the ike.preshared file.


        # ikeadm read preshared

ProcedureHow to View IKE Preshared Keys

By default, the ikeadm command prevents you from viewing the actual keys in a dump of a Phase 1 SA. Viewing the keys is useful during debugging.

To view the actual keys, you must increase the privilege level of the daemon. For a description of the privilege levels, see IKE Administration Command.

Note –

To perform this procedure on a release prior to the Solaris 10 4/09 release, see Example 23–2.

Before You Begin

IKE is configured and the ike service is running.

  1. View the IKE preshared keys.


    # ikeadm
ikeadm> dump preshared

  2. If you get an error, increase the privilege level of the in.iked daemon.

    1. Increase the privilege level of the in.iked daemon in the SMF repository.


      # svcprop -p config/admin_privilege ike
base
# svccfg -s ike setprop config/admin_privilege=keymat

    2. Increase the privilege level of the running in.iked daemon.


      # svcadm refresh ike ; svcadm restart ike

    3. (Optional) Confirm that the privilege level is keymat.


      # svcprop -p config/admin_privilege ike
keymat

    4. View the keys by running Step 1 again.

  3. Return the IKE daemon to the base privilege level.

    1. After you view the keys, return the privilege level to the default.


      # svccfg -s ike setprop config/admin_privilege=base

    2. Refresh and then restart IKE.


      # svcadm refresh ike ; svcadm restart ike
Example 23–2 Verifying IKE Preshared Keys in a Release Prior to the Solaris 10 4/09 Release

In the following example, the administrator is viewing keys on a Solaris system that is not running the current Solaris release. The administrator wants to verify that the keys on this system are identical to the keys on the communicating system. After verifying that the keys on the two systems are identical, the administrator restores the privilege level to 0.

ProcedureHow to Add an IKE Preshared Key for a New Policy Entry in ipsecinit.conf

If you add IPsec policy entries while IPsec and IKE are running, you must read the new policy and IKE rules into the kernel. Starting in the Solaris 10 4/09 release, you restart the policy service and refresh the ike service after you add the new keys.

Note –

To perform this procedure on a release prior to the Solaris 10 4/09 release, see Example 23–3.

Before You Begin

This procedure assumes the following:

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. On this system, generate random numbers and construct a key of 64 to 448 bits.

    For details, see How to Generate Random Numbers on a Solaris System. If you are generating a preshared key for a Solaris system that is communicating with an operating system that requires ASCII, see Example 23–1.

  3. By some means, send the key to the administrator of the remote system.

    You both need to add the same preshared key at the same time. Your key is only as safe as the safety of your transmission mechanism. An out-of-band mechanism, such as registered mail or a protected fax machine, is best. You can also use an ssh session to administer both systems.

  4. Create a rule for IKE to manage the keys for enigma and ada.

    1. On the enigma system, add the following rule to the /etc/inet/ike/config file:


      ### ike/config file on enigma, 192.168.116.16
 
## The rule to communicate with ada

{label "enigma-to-ada"
 local_addr 192.168.116.16
 remote_addr 192.168.15.7
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
	}

    2. On the ada system, add the following rule:


      ### ike/config file on ada, 192.168.15.7
 
## The rule to communicate with enigma

{label "ada-to-enigma"
 local_addr 192.168.15.7
 remote_addr 192.168.116.16
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
}

  5. Ensure that IKE preshared keys are available at reboot.

    1. On the enigma system, add the following information to the /etc/inet/secret/ike.preshared file:


      # ike.preshared on enigma for the ada interface
# 
{ localidtype IP
  localid 192.168.116.16
  remoteidtype IP
  remoteid 192.168.15.7
  # enigma and ada's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

    2. On the ada system, add the following information to the ike.preshared file:


      # ike.preshared on ada for the enigma interface
# 
{ localidtype IP
  localid 192.168.15.7
  remoteidtype IP
  remoteid 192.168.116.16
  # ada and enigma's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

  6. On each system, restart the IPsec policy service to secure the added interface.


    # svcadm restart policy

  7. On each system, refresh the ike service.


    # svcadm refresh ike

  8. Verify that the systems can communicate.

    See How to Verify That IKE Preshared Keys Are Identical.

Example 23–3 Adding an IKE Preshared Key for a New IPsec Policy Entry

In the following example, the administrator is adding preshared key to a Solaris system that is not running the current Solaris release. The administrator follows the preceding procedure to modify the ike/config and ike.preshared files, and to generate keys and contact the remote system. The administrator uses different commands to read the new IPsec policy and IKE rules into the kernel.

ProcedureHow to Verify That IKE Preshared Keys Are Identical

If the preshared keys on the communicating systems are not identical, the systems cannot authenticate.

Before You Begin

IPsec has been configured and is enabled between the two systems that you are testing. You are running the current Solaris 10 release.

Note –

To perform this procedure on a release prior to the Solaris 10 4/09 release, see Example 23–2.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. On each system, check the privilege level of the in.iked daemon.


    # svcprop -p config/admin_privilege ike
base

    • If the privilege level is keymat, continue with Step 3.

    • If the privilege level is base or modkeys, increase the privilege level.

      Then, refresh and restart the ike service.


      # svccfg -s ike setprop config/admin_privilege=keymat
# svcadm refresh ike ; svcadm restart ike
# svcprop -p config/admin_privilege ike
keymat

  3. On each system, view the preshared key information.


    # ikeadm dump preshared
PSKEY: Preshared key (24 bytes): f47cb…/192
LOCIP: AF_INET: port 0, 192.168.116.16 (enigma).
REMIP: AF_INET: port 0, 192.168.13.213 (partym).

  4. Compare the two dumps.

    If the preshared keys are not identical, replace one key with the other key in the /etc/inet/secret/ike.preshared file.

  5. When the verification is complete, return the privilege level to the default on each system.


    # svccfg -s ike setprop config/admin_privilege=base
# svcadm restart ike

Configuring IKE With Public Key Certificates (Task Map)

The following table provides pointers to procedures for creating public key certificates for IKE. The procedures include how to accelerate and store the certificates on attached hardware.

Task 

Description 

For Instructions 

Configure IKE with self-signed public key certificates 

Creates and places two certificates on each system: 

  • A self-signed certificate

  • The public key certificate from the remote system

How to Configure IKE With Self-Signed Public Key Certificates

Configure IKE with a PKI Certificate Authority 

Creates a certificate request, and then places three certificates on each system: 

  • The certificate that the Certificate Authority (CA) creates from your request

  • The public key certificate from the CA

  • The CRL from the CA

How to Configure IKE With Certificates Signed by a CA

Configure public key certificates on local hardware 

Involves one of:  

  • Generating a self-signed certificate on the local hardware and then adding the public key from a remote system to the hardware.

  • Generating a certificate request on the local hardware and then adding the public key certificates from the CA to the hardware.

How to Generate and Store Public Key Certificates on Hardware

Update the certificate revocation list (CRL) from a PKI 

Accesses the CRL from a central distribution point. 

How to Handle a Certificate Revocation List

Configuring IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Unlike preshared keys, a public key certificate can be used on a mobile machine or on a system that might be renumbered.

Public key certificates can also be stored on attached hardware. For the procedure, see Configuring IKE to Find Attached Hardware (Task Map).

ProcedureHow to Configure IKE With Self-Signed Public Key Certificates

Self-signed certificates require less overhead than public certificates from a CA, but do not scale very easily.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Add a self-signed certificate to the ike.privatekeys database. 


    # ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]
    -ks

    Creates a self-signed certificate.

    -kc

    Creates a certificate request. For the procedure, see How to Configure IKE With Certificates Signed by a CA.

    -m keysize

    Is the size of the key. The keysize can be 512, 1024, 2048, 3072, or 4096.

    -t keytype

    Specifies the type of algorithm to use. The keytype can be rsa-sha1, rsa-md5, or dsa-sha1.

    -D dname

    Is the X.509 distinguished name for the certificate subject. The dname typically has the form: C=country, O=organization, OU=organizational unit, CN=common name. Valid tags are C, O, OU, and CN.

    -A altname

    Is the alternate name for the certificate. The altname is in the form of tag=value. Valid tags are IP, DNS, email, and DN.

    -S validity-start-time

    Provides an absolute or relative valid start time for the certificate.

    -F validity-end-time

    Provides an absolute or relative valid end time for the certificate.

    -T token-ID

    Enables a PKCS #11 hardware token to generate the keys. The certificates are then stored in the hardware.

    1. For example, the command on the partym system would appear similar to the following:


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. The command on the enigma system would appear similar to the following:


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  3. Save the certificate and send it to the remote system.

    You can paste the certificate into an email.

    1. For example, you would send the following partym certificate to the enigma administrator:


      To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. The enigma administrator would send you the following enigma certificate:


      To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  4. On each system, add the certificate that you received.

    1. Copy the public key from the administrator's email.

    2. Type the ikecert certdb -a command and press the Return key.

      No prompts display when you press the Return key.


      # ikecert certdb -a Press the Return key

    3. Paste the public key. Then press the Return key. To end the entry, press Control-D.


      -----BEGIN X509 CERTIFICATE-----
MIIC…
…
----END X509 CERTIFICATE----- Press the Return key
<Control>-D

  5. Verify with the other administrator that the certificate is from that administrator.

    For example, you can telephone the other administrator to compare the values of the public key hash. The public key hash for the shared certificate must be identical on the two systems.

    1. List the stored certificate on your system.

      For example, on the partym system, the public certificate is in slot 1, and the private certificate is in slot 0.


      partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. Compare this value with the public key hash on the enigma system.

      You can read the public key hash over the telephone.


      enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

  6. On each system, trust both certificates.

    Edit the /etc/inet/ike/config file to recognize the certificates.

    The administrator of the remote system provides the values for the cert_trust, remote_addr, and remote_id parameters.

    1. For example, on the partym system, the ike/config file would appear similar to the following:


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## Parameters that may also show up in rules.

p1_xform 
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 5

{
 label "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    2. On the enigma system, add enigma values for local parameters in the ike/config file.

      For the remote parameters, use partym values. Ensure that the value for the label keyword is unique. This value must be different from the remote system's label value.


      …
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…
Example 23–4 Verifying That a Certificate From Another Administrator is Valid

In this example, the administrators use the Subject Name to verify that the certificates are identical.

The first administrator saves the output of generating and listing the certificate to a file. Because the output of the ikecert command prints to standard error, the administrator redirects standard error to the file.


sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

The administrator verifies the contents of the file.


sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Then, the administrator sends the file in an email to the second administrator.

The second administrator places the file in a secure directory, then imports the certificate from the file.


sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

The ikecert command imports only the text between the -----BEGIN and -----END lines. The administrator verifies that the local certificate has the same public key hash as the public key hash in the co2sys file.


sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

To ensure that the first administrator sent this email, the second administrator telephones the first administrator to verify the Subject Name of the certificate.

Example 23–5 Specifying a Start Time and an End Time for a Certificate

In this example, the administrator on the partym system establishes dates within which the certificate is valid. The certificate is backdated by 2 1/2 days, and is valid for 4 years and 6 months from the date of creation.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

The administrator on the enigma system establishes dates within which the certificate is valid. The certificate is backdated by 2 days and is valid until midnight of December 31, 2010.


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

ProcedureHow to Configure IKE With Certificates Signed by a CA

Public certificates from a Certificate Authority (CA) require negotiation with an outside organization. The certificates very easily scale to protect a large number of communicating systems.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Use the ikecert certlocal -kc command to create a certificate request.

    For a description of the arguments to the command, see Step 2 in How to Configure IKE With Self-Signed Public Key Certificates.


    # ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

    1. For example, the following command creates a certificate request on the partym system:


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

    2. The following command creates a certificate request on the enigma system:


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

  3. Submit the certificate request to a PKI organization.

    The PKI organization can tell you how to submit the certificate request. Most organizations have a web site with a submission form. The form requires proof that the submission is legitimate. Typically, you paste your certificate request into the form. When your request has been checked by the organization, the organization issues you the following two certificate objects and a list of revoked certificates:

    • Your public key certificate – This certificate is based on the request that you submitted to the organization. The request that you submitted is part of this public key certificate. The certificate uniquely identifies you.

    • A Certificate Authority – The organization's signature. The CA verifies that your public key certificate is legitimate.

    • A Certificate Revocation List (CRL) – The latest list of certificates that the organization has revoked. The CRL is not sent separately as a certificate object if access to the CRL is embedded in the public key certificate.

      When a URI for the CRL is embedded in the public key certificate, IKE can automatically retrieve the CRL for you. Similarly, when a DN (directory name on an LDAP server) entry is embedded in the public key certificate, IKE can retrieve and cache the CRL from an LDAP server that you specify.

      See How to Handle a Certificate Revocation List for an example of an embedded URI and an embedded DN entry in a public key certificate.

  4. Add each certificate to your system.

    The -a option to the ikecert certdb -a adds the pasted object to the appropriate certificate database on your system. For more information, see IKE With Public Key Certificates.

    1. On the system console, assume the Primary Administrator role or become superuser.

    2. Add the public key certificate that you received from the PKI organization.


      # ikecert certdb -a
Press the Return key
Paste the certificate:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    3. Add the CA from the PKI organization.


      # ikecert certdb -a
Press the Return key
Paste the CA:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    4. If the PKI organization has sent a list of revoked certificates, add the CRL to the certrldb database:


      # ikecert certrldb -a
Press the Return key
Paste the CRL:
-----BEGIN CRL-----
…
-----END CRL----
Press the Return key
<Control>-D

  5. Use the cert_root keyword to identify the PKI organization in the /etc/inet/ike/config file.

    Use the name that the PKI organization provides.

    1. For example, the ike/config file on the partym system might appear similar to the following:


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform 
 { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "US-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}
      Note –

      All arguments to the auth_method parameter must be on the same line.

    2. On the enigma system, create a similar file.

      Specifically, the enigma ike/config file should do the following:

      • Include the same cert_root value.

      • Use enigma values for local parameters.

      • Use partym values for remote parameters.

      • Create a unique value for the label keyword. This value must be different from the remote system's label value.


      …
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

  6. Tell IKE how to handle CRLs.

    Choose the appropriate option:

    • No CRL available

      If the PKI organization does not provide a CRL, add the keyword ignore_crls to the ike/config file.


      # Trusted root cert
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,…
ignore_crls
…

      The ignore_crls keyword tells IKE not to search for CRLs.

    • CRL available

      If the PKI organization provides a central distribution point for CRLs, you can modify the ike/config file to point to that location.

      See How to Handle a Certificate Revocation List for examples.

Example 23–6 Using rsa_encrypt When Configuring IKE

    When you use auth_method rsa_encrypt in the ike/config file, you must add the peer's certificate to the publickeys database.

  1. Send the certificate to the remote system's administrator.

    You can paste the certificate into an email.

    For example, the partym administrator would send the following email:


    To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII…
----END X509 CERTIFICATE-----

    The enigma administrator would send the following email:


    To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII
…
-----END X509 CERTIFICATE-----

  2. On each system, add the emailed certificate to the local publickeys database. 


    # ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

The authentication method for RSA encryption hides identities in IKE from eavesdroppers. Because the rsa_encrypt method hides the peer's identity, IKE cannot retrieve the peer's certificate. As a result, the rsa_encrypt method requires that the IKE peers know each other's public keys.

Therefore, when you use an auth_method of rsa_encrypt in the /etc/inet/ike/config file, you must add the peer's certificate to the publickeys database. The publickeys database then holds three certificates for each communicating pair of systems:

Troubleshooting – The IKE payload, which includes the three certificates, can become too large for rsa_encrypt to encrypt. Errors such as “authorization failed” and “malformed payload” can indicate that the rsa_encrypt method cannot encrypt the total payload. Reduce the size of the payload by using a method, such as rsa_sig, that requires only two certificates.

ProcedureHow to Generate and Store Public Key Certificates on Hardware

Generating and storing public key certificates on hardware is similar to generating and storing public key certificates on your system. On hardware, the ikecert certlocal and ikecert certdb commands must identify the hardware. The -T option with the token ID identifies the hardware to the commands.

Before You Begin

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Generate a self-signed certificate or a certificate request, and specify the token ID.

    Choose one of the following options:

    Note –

    The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.

    • For a self-signed certificate, use this syntax.


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

      The argument to the -T option is the token ID from the attached Sun Crypto Accelerator 4000 board.

    • For a certificate request, use this syntax.


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

    For a description of the arguments to the ikecert command, see the ikecert(1M) man page.

  3. At the prompt for a PIN, type the Sun Crypto Accelerator 4000 user, a colon, and the user's password.

    If the Sun Crypto Accelerator 4000 board has a user ikemgr whose password is rgm4tigt, you would type the following:


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
    Note –

    The PIN response is stored on disk as clear text.

    After you type the password, the certificate prints out:


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

  4. Send your certificate for use by the other party.

    Choose one of the following options:

    • Send the self-signed certificate to the remote system.

      You can paste the certificate into an email.

    • Send the certificate request to an organization that handles PKI.

      Follow the instructions of the PKI organization to submit the certificate request. For a more detailed discussion, see Step 3 of How to Configure IKE With Certificates Signed by a CA.

  5. On your system, edit the /etc/inet/ike/config file to recognize the certificates.

    Choose one of the following options.

    • Self-signed certificate

      Use the values that the administrator of the remote system provides for the cert_trust, remote_id, and remote_addr parameters. For example, on the enigma system, the ike/config file would appear similar to the following:


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name


# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    • Certificate request

      Type the name that the PKI organization provides as the value for the cert_root keyword. For example, the ike/config file on the enigma system might appear similar to the following:


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

  6. Place the certificates from the other party in the hardware.

    Respond to the PIN request as you responded in Step 3.

    Note –

    You must add the public key certificates to the same attached hardware that generated your private key.

    • Self-signed certificate.

      Add the remote system's self-signed certificate. In this example, the certificate is stored in the file, DCA.ACCEL.STOR.CERT.


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password

      If the self-signed certificate used rsa_encrypt as the value for the auth_method parameter, add the peer's certificate to the hardware store.

    • Certificates from a PKI organization.

      Add the certificate that the organization generated from your certificate request, and add the certificate authority (CA).


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT
Enter PIN for PKCS#11 token: Type user:password

      To add a certificate revocation list (CRL) from the PKI organization, see How to Handle a Certificate Revocation List.

ProcedureHow to Handle a Certificate Revocation List

A certificate revocation list (CRL) contains outdated or compromised certificates from a Certificate Authority. You have four ways to handle CRLs.

The following procedure describes how to instruct IKE to use CRLs from a central distribution point.

  1. Display the certificate that you received from the CA.


    # ikecert certdb -lv certspec
    -l

    Lists certificates in the IKE certificate database.

    -v

    Lists the certificates in verbose mode. Use this option with care.

    certspec

    Is a pattern that matches a certificate in the IKE certificate database.

    For example, the following certificate was issued by Sun Microsystems. Details have been altered.


    # ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A…A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

    Notice the CRL Distribution Points entry. The URI entry indicates that this organization's CRL is available on the web. The DN entry indicates that the CRL is available on an LDAP server. Once accessed by IKE, the CRL is cached for further use.

    To access the CRL, you need to reach a distribution point.

  2. Choose one of the following methods to access the CRL from a central distribution point.

    • Use the URI.

      Add the keyword use_http to the host's /etc/inet/ike/config file. For example, the ike/config file would appear similar to the following:


      # Use CRL from organization's URI
use_http
…

    • Use a web proxy.

      Add the keyword proxy to the ike/config file. The proxy keyword takes a URL as an argument, as in the following:


      # Use own web proxy
proxy "http://proxy1:8080"

    • Use an LDAP server.

      Name the LDAP server as an argument to the ldap-list keyword in the host's /etc/inet/ike/config file. Your organization provides the name of the LDAP server. The entry in the ike/config file would appear similar to the following:


      # Use CRL from organization's LDAP
ldap-list "ldap1.sun.com:389,ldap2.sun.com"
…

    IKE retrieves the CRL and caches the CRL until the certificate expires.

Example 23–7 Pasting a CRL Into the Local certrldb Database

If the PKI organization's CRL is not available from a central distribution point, you can add the CRL manually to the local certrldb database. Follow the PKI organization's instructions for extracting the CRL into a file, then add the CRL to the database with the ikecert certrldb -a command.


# ikecert certrldb -a < Sun.Cert.CRL

Configuring IKE for Mobile Systems (Task Map)

The following table points to procedures to configure IKE to handle systems that log in remotely to a central site.

Task 

Description 

For Instructions 

Communicate with a central site from off-site 

Enables off-site systems to communicate with a central site. The off-site systems might be mobile. 

How to Configure IKE for Off-Site Systems

Use a root certificate and IKE on a central system that accepts traffic from mobile systems 

Configures a gateway system to accept IPsec traffic from a system that does not have a fixed IP address. 

Example 23–8

Use a root certificate and IKE on a system that does not have a fixed IP address 

Configures a mobile system to protect its traffic to a central site, such as company headquarters. 

Example 23–9

Use self-signed certificates and IKE on a central system that accepts traffic from mobile systems 

Configures a gateway system with self-signed certificates to accept IPsec traffic from a mobile system. 

Example 23–10

Use self-signed certificates and IKE on a system that does not have a fixed IP address 

Configures a mobile system with self-signed certificates to protect its traffic to a central site. 

Example 23–11

Configuring IKE for Mobile Systems

When configured properly, home offices and mobile laptops can use IPsec and IKE to communicate with their company's central computers. A blanket IPsec policy that is combined with a public key authentication method enables off-site systems to protect their traffic to a central system.

ProcedureHow to Configure IKE for Off-Site Systems

IPsec and IKE require a unique ID to identify source and destination. For off-site or mobile systems that do not have a unique IP address, you must use another ID type. ID types such as DNS, DN, or email can be used to uniquely identify a system.

Off-site or mobile systems that have unique IP addresses are still best configured with a different ID type. For example, if the systems attempt to connect to a central site from behind a NAT box, their unique addresses are not used. A NAT box assigns an arbitrary IP address, which the central system would not recognize.

Preshared keys also do not work well as an authentication mechanism for mobile systems, because preshared keys require fixed IP addresses. Self-signed certificates, or certificates from a PKI enable mobile systems to communicate with the central site.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Configure the central system to recognize mobile systems.

    1. Set up the /etc/hosts file.

      The central system does not have to recognize specific addresses for the mobile systems.


      # /etc/hosts on central
central 192.xxx.xxx.x

    2. Set up the ipsecinit.conf file.

      The central system needs a policy that allows a wide range of IP addresses. Later, certificates in the IKE policy ensure that the connecting systems are legitimate.


      # /etc/inet/ipsecinit.conf on central
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. Set up the ike.config file.

      DNS identifies the central system. Certificates are used to authenticate the system.


      ## /etc/inet/ike/ike.config on central
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# List self-signed certificates - trust server and enumerated others
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=root@central.domain.org"
#cert_trust    "email=user1@mobile.domain.org"
#

# Rule for mobile systems with certificate
{
  label "Mobile systems with certificate"
  local_id_type DNS

# Any mobile system who knows my DNS or IP can find me.

  local_id "central.domain.org"
  local_addr 192.xxx.xxx.x

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  3. Log in to each mobile system, and configure the system to find the central system.

    1. Set up the /etc/hosts file.

      The /etc/hosts file does not need an address for the mobile system, but can provide one. The file must contain a public IP address for the central system.


      # /etc/hosts on mobile
mobile 10.x.x.xx
central 192.xxx.xxx.x

    2. Set up the ipsecinit.conf file.

      The mobile system needs to find the central system by its public IP address. The systems must configure the same IPsec policy.


      # /etc/inet/ipsecinit.conf on mobile
# Find central
{raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. Set up the ike.config file.

      The identifier cannot be an IP address. The following identifiers are valid for mobile systems:

      • DN=ldap-directory-name

      • DNS=domain-name-server-address

      • email=email-address

      Certificates are used to authenticate the mobile system.


      ## /etc/inet/ike/ike.config on mobile
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# Self-signed certificates - trust me and enumerated others
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=user1@domain.org"
#cert_trust    "email=root@central.domain.org"
#
# Rule for off-site systems with root certificate
{
	label "Off-site mobile with certificate"
	local_id_type DNS

# NAT-T can translate local_addr into any public IP address
# central knows me by my DNS

	local_id "mobile.domain.org"
	local_addr 0.0.0.0/0

# Find central and trust the root certificate
	remote_id "central.domain.org"
	remote_addr 192.xxx.xxx.x

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  4. Read the IKE configuration into the kernel.

    • Starting in the Solaris 10 4/09 release, enable the ike service.


      # svcadm enable svc:/network/ipsec/ike

    • If you are running a release prior to the Solaris 10 4/09 release, reboot the system.


      # init 6

      Or, stop and start the in.iked daemon.

Example 23–8 Configuring a Central Computer to Accept IPsec Traffic From a Mobile System

IKE can initiate negotiations from behind a NAT box. However, the ideal setup for IKE is without an intervening NAT box. In the following example, root certificates have been issued by a CA. The CA certificates have been placed on the mobile system and the central system. A central system accepts IPsec negotiations from a system behind a NAT box. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 23–9.


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}
Example 23–9 Configuring a System Behind a NAT With IPsec

In the following example, root certificates have been issued by a CA and placed on the mobile system and the central system. mobile1 is connecting to the company headquarters from home. The Internet service provider (ISP) network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. For setting up the computer at company headquarters, see Example 23–8.


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
Example 23–10 Accepting Self-Signed Certificates From a Mobile System

In the following example, self-signed certificates have been issued and are on the mobile and the central system. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 23–11.


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
Example 23–11 Using Self-Signed Certificates to Contact a Central System

In the following example, mobile1 is connecting to the company headquarters from home. The certificates have been issued and placed on the mobile and the central system. The ISP network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. To set up the computer at company headquarters, see Example 23–10.


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Configuring IKE to Find Attached Hardware (Task Map)

The following table points to procedures that inform IKE about attached hardware. You must inform IKE about attached hardware before IKE can use the hardware. To use the hardware, follow the hardware procedures in Configuring IKE With Public Key Certificates.

Note –

You do not have to inform IKE about on-chip hardware. For example, the UltraSPARC® T2 processor provides cryptographic acceleration. You do not need to configure IKE to find the on-chip accelerators.

Task 

Description 

For Instructions 

Offload IKE key operations to the Sun Crypto Accelerator 1000 board 

Links IKE to the PKCS #11 library. 

How to Configure IKE to Find the Sun Crypto Accelerator 1000 Board

Offload IKE key operations and store the keys on the Sun Crypto Accelerator 4000 board 

Links IKE to the PKCS #11 library and lists the name of the attached hardware. 

How to Configure IKE to Find the Sun Crypto Accelerator 4000 Board

Configuring IKE to Find Attached Hardware

Public key certificates can also be stored on attached hardware. The Sun Crypto Accelerator 1000 board provides storage only. The Sun Crypto Accelerator 4000 and the Sun Crypto Accelerator 6000 board provide storage, and enable public key operations to be offloaded from the system to the board.

ProcedureHow to Configure IKE to Find the Sun Crypto Accelerator 1000 Board

Before You Begin

The following procedure assumes that a Sun Crypto Accelerator 1000 board is attached to the system. The procedure also assumes that the software for the board has been installed and that the software has been configured. For instructions, see the Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Check that the PKCS #11 library is linked.

    Type the following command to determine whether a PKCS #11 library is linked:


    # ikeadm get stats
Phase 1 SA counts:
Current:   initiator:          0   responder:          0
Total:     initiator:          0   responder:          0
Attempted: initiator:          0   responder:          0
Failed:    initiator:          0   responder:          0
           initiator fails include 0 time-out(s)
PKCS#11 library linked in from /usr/lib/libpkcs11.so
#

  3. Solaris 10 1/06: Starting in this release, you can store keys in the softtoken keystore.

    For information on the keystore that is provided by the Solaris cryptographic framework, see the cryptoadm(1M) man page. For an example of using the keystore, see Example 23–12.

ProcedureHow to Configure IKE to Find the Sun Crypto Accelerator 4000 Board

Before You Begin

The following procedure assumes that a Sun Crypto Accelerator 4000 board is attached to the system. The procedure also assumes that the software for the board has been installed and that the software has been configured. For instructions, see the Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.

If you are using a Sun Crypto Accelerator 6000 board, see the Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide for instructions.

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Check that the PKCS #11 library is linked.

    IKE uses the library's routines to handle key generation and key storage on the Sun Crypto Accelerator 4000 board. Type the following command to determine whether a PKCS #11 library has been linked:


    $ ikeadm get stats
…
PKCS#11 library linked in from /usr/lib/libpkcs11.so
$
    Note –

    The Sun Crypto Accelerator 4000 board supports keys up to 2048 bits for RSA. For DSA, this board supports keys up to 1024 bits.

  3. Find the token ID for the attached Sun Crypto Accelerator 4000 board.


    $ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                     "

    The library returns a token ID, also called a keystore name, of 32 characters. In this example, you could use the Sun Metaslot token with the ikecert commands to store and accelerate IKE keys.

    For instructions on how to use the token, see How to Generate and Store Public Key Certificates on Hardware.

    The trailing spaces are automatically padded by the ikecert command.

Example 23–12 Finding and Using Metaslot Tokens

Tokens can be stored on disk, on an attached board, or in the softtoken keystore that the Solaris encryption framework provides. The softtoken keystore token ID might resemble the following.


$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

To create a passphrase for the softtoken keystore, see the pktool(1) man page.

A command that resembles the following would add a certificate to the softtoken keystore. Sun.Metaslot.cert is a file that contains the CA certificate.


# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Changing IKE Transmission Parameters (Task Map)

The following table points to procedures to configure transmission parameters for IKE.

Task 

Description 

For Instructions 

Make key negotiation more efficient 

Changes the key negotiation parameters. 

How to Change the Duration of Phase 1 IKE Key Negotiation

Configure key negotiation to allow for delays in transmission 

Lengthens the key negotiation parameters. 

Example 23–13

Configure key negotiation to succeed quickly, or to show failures quickly 

Shortens the key negotiation parameters. 

Example 23–14

Changing IKE Transmission Parameters

When IKE negotiates keys, the speed of transmission can affect the success of the negotiation. Normally, you would not need to change the default values for IKE transmission parameters. However, when optimizing key negotiation over very dirty lines, or when reproducing a problem, you might want to change the transmission values.

Longer duration times enable IKE to negotiate keys over unreliable transmission lines. You can lengthen certain parameters so that initial attempts succeed. If the initial attempt does not succeed, you can space subsequent attempts to offer more time for success.

Shorter duration times enable you to take advantage of reliable transmission lines. You can more quickly retry a failed negotiation to speed up the negotiation. When diagnosing a problem, you might also want to speed up the negotiation for a quick failure. Shorter durations also enable the Phase 1 SAs to be used for their lifetime.

ProcedureHow to Change the Duration of Phase 1 IKE Key Negotiation

  1. On the system console, assume the Primary Administrator role or become superuser.

    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 secure remote login.

  2. Change the default values of the global transmission parameters on each system.

    On each system, modify Phase 1 duration parameters the /etc/inet/ike/config file.


    ### ike/config file on system

## Global parameters
#
## Phase 1 transform defaults
#
#expire_timer      300
#retry_limit         5
#retry_timer_init    0.5 (integer or float)
#retry_timer_max    30   (integer or float)
    expire_timer

    The number of seconds to let a not-yet-complete IKE Phase I negotiation linger before deleting the negotiation attempt. By default, the attempt lingers for 30 seconds.

    retry_limit

    The number of retransmits before any IKE negotiation is aborted. By default, IKE tries five times.

    retry_timer_init

    The initial interval between retransmits. This interval is doubled until the retry_timer_max value is reached. The initial interval is 0.5 seconds.

    retry_timer_max

    The maximum interval in seconds between retransmits. The retransmit interval stops growing at this limit. By default, the limit is 30 seconds.

  3. Read the changed configuration into the kernel.

    • Starting in the Solaris 10 4/09 release, refresh the ike service.


      # svcadm refresh svc:/network/ipsec/ike

    • If you are running a release prior to the Solaris 10 4/09 release, reboot the system.


      # init 6

      Or, stop and start the in.iked daemon.

Example 23–13 Lengthening IKE Phase 1 Negotiation Times

In the following example, a system is connected to its IKE peers by a high-traffic transmission line. The original settings are in comments in the file. The new settings lengthen the negotiation time.


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180
Example 23–14 Shortening IKE Phase 1 Negotiation Times

In the following example, a system is connected to its IKE peers by a high-speed line with little traffic. The original settings are in comments in the file. The new settings shorten the negotiation time.


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20

Chapter 24 Internet Key Exchange (Reference)

This chapter contains the following reference information about IKE:

For instructions on implementing IKE, see Chapter 23, Configuring IKE (Tasks). For overview information, see Chapter 22, Internet Key Exchange (Overview).

IKE Service Management Facility

svc:/network/ipsec/ike:default service – The service management facility (SMF) provides the ike service to manage IKE. By default, this service is disabled. Before enabling this service, you must create an IKE configuration file, /etc/inet/ike/config.

The following ike service properties are configurable:

For information about SMF, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration. Also see the smf(5), svcadm(1M), and svccfg(1M) man pages.

IKE Daemon

The in.iked daemon automates the management of cryptographic keys for IPsec on a Solaris system. The daemon negotiates with a remote system that is running the same protocol to provide authenticated keying materials for security associations (SAs) in a protected manner. The daemon must be running on all systems that plan to communicate securely.

By default, the svc:/network/ipsec/ike:default service is not enabled. After you have configured the /etc/inet/ike/config file and enabled the ike service, the in.iked daemon runs at system boot.

When the IKE daemon runs, the system authenticates itself to its peer IKE entity in the Phase 1 exchange. The peer is defined in the IKE policy file, as are the authentication methods. The daemon then establishes the keys for the Phase 2 exchange. At an interval specified in the policy file, the IKE keys are refreshed automatically. The in.iked daemon listens for incoming IKE requests from the network and for requests for outbound traffic through the PF_KEY socket. For more information, see the pf_key(7P) man page.

Two commands support the IKE daemon. The ikeadm command can be used to view and temporarily modify the IKE policy. To permanently modify IKE policy, you modify properties of the ike service. For the procedure, see How to View IKE Preshared Keys.

The ikecert command enables you to view and manage the public key databases. This command manages the local databases, ike.privatekeys and publickeys. This command also manages public key operations and the storage of public keys on hardware.

IKE Policy File

The configuration file for the IKE policy, /etc/inet/ike/config, manages the keys for the interfaces that are being protected in the IPsec policy file, /etc/inet/ipsecinit.conf. The IKE policy file manages keys for IKE, and for the IPsec SAs. The IKE daemon itself requires keying material in the Phase 1 exchange.

Key management with IKE includes rules and global parameters. An IKE rule identifies the systems or networks that the keying material secures. The rule also specifies the authentication method. Global parameters include such items as the path to an attached hardware accelerator. For examples of IKE policy files, see Configuring IKE With Preshared Keys (Task Map). For examples and descriptions of IKE policy entries, see the ike.config(4) man page.

The IPsec SAs that IKE supports protect the IP datagrams according to policies that are set up in the configuration file for the IPsec policy, /etc/inet/ipsecinit.conf. The IKE policy file determines if perfect forward security (PFS) is used when creating the IPsec SAs.

The ike/config file can include the path to a library that is implemented according to the following standard: RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki). IKE uses this PKCS #11 library to access hardware for key acceleration and key storage.

The security considerations for the ike/config file are similar to the considerations for the ipsecinit.conf file. For details, see Security Considerations for ipsecinit.conf and ipsecconf.

IKE Administration Command

You can use the ikeadm command to do the following:

For examples and a full description of this command's options, see the ikeadm(1M) man page.

The privilege level of the running IKE daemon determines which aspects of the IKE daemon can be viewed and modified. Three levels of privilege are possible.

base level

You cannot view or modify keying material. The base level is the default level of privilege.

modkeys level

You can remove, change, and add preshared keys.

keymat level

You can view the actual keying material with the ikeadm command.

For a temporary privilege change, you can use the ikeadm command. For a permanent change, change the admin_privilege property of the ike service. For the procedure, see How to Manage IKE and IPsec Services.

The security considerations for the ikeadm command are similar to the considerations for the ipseckey command. For details, see Security Considerations for ipseckey.

IKE Preshared Keys Files

When you create preshared keys manually, the keys are stored in files in the /etc/inet/secret directory. The ike.preshared file contains the preshared keys for Internet Security Association and Key Management Protocol (ISAKMP) SAs. The ipseckeys file contains the preshared keys for IPsec SAs. The files are protected at 0600. The secret directory is protected at 0700.

Note –

Preshared keys cannot take advantage of hardware storage. Preshared keys are generated and are stored on the system.

IKE Public Key Databases and Commands

The ikecert command manipulates the local system's public key databases. You use this command when the ike/config file requires public key certificates. Because IKE uses these databases to authenticate the Phase 1 exchange, the databases must be populated before activating the in.iked daemon. Three subcommands handle each of the three databases: certlocal, certdb, and certrldb.

The ikecert command also handles key storage. Keys can be stored on disk, on an attached Sun Crypto Accelerator 6000 or Sun Crypto Accelerator 4000 board, or in a softtoken keystore. The softtoken keystore is available when the metaslot in the Solaris cryptographic framework is used to communicate with the hardware device. The ikecert command uses the PKCS #11 library to locate key storage.

For more information, see the ikecert(1M) man page. For information about metaslot and the softtoken keystore, see the cryptoadm(1M) man page.

ikecert tokens Command

The tokens argument lists the token IDs that are available. Token IDs enable the ikecert certlocal and ikecert certdb commands to generate public key certificates and certificate requests. The certificates and certificate requests can also be stored by the cryptographic framework in the softtoken keystore, or on an attached Sun Crypto Accelerator 6000 or Sun Crypto Accelerator 4000 board. The ikecert command uses the PKCS #11 library to locate certificate storage.

ikecert certlocal Command

The certlocal subcommand manages the private key database. Options to this subcommand enable you to add, view, and remove private keys. This subcommand also creates either a self-signed certificate or a certificate request. The -ks option creates a self-signed certificate. The -kc option creates a certificate request. Keys are stored on the system in the /etc/inet/secret/ike.privatekeys directory, or on attached hardware with the -T option.

When you create a private key, the options to the ikecert certlocal command must have related entries in the ike/config file. The correspondences between ikecert options and ike/config entries are shown in the following table.

Table 24–1 Correspondences Between ikecert Options and ike/config Entries

ikecert Option

ike/config Entry

Description 

-A subject-alternate-name

cert_trust subject-alternate-name

A nickname that uniquely identifies the certificate. Possible values are an IP address, an email address, or a domain name. 

-D X.509-distinguished-name

X.509-distinguished-name

The full name of the certificate authority that includes the country (C), organization name (ON), organizational unit (OU), and common name (CN). 

-t dsa-sha1

auth_method dss_sig

An authentication method that is slightly slower than RSA.

-t rsa-md5 and

-t rsa-sha1

auth_method rsa_sig

An authentication method that is slightly faster than DSA.

The RSA public key must be large enough to encrypt the biggest payload. Typically, an identity payload, such as the X.509 distinguished name, is the biggest payload.

-t rsa-md5 and

-t rsa-sha1

auth_method rsa_encrypt

RSA encryption hides identities in IKE from eavesdroppers, but requires that the IKE peers know each other's public keys. 

-T

pkcs11_path

The PKCS #11 library handles key acceleration on the Sun Crypto Accelerator 1000 board, the Sun Crypto Accelerator 6000 board, and the Sun Crypto Accelerator 4000 board. The library also provides the tokens that handle key storage on the Sun Crypto Accelerator 6000 and Sun Crypto Accelerator 4000 boards.

If you issue a certificate request with the ikecert certlocal -kc command, you send the output of the command to a PKI organization or to a certificate authority (CA). If your company runs its own PKI, you send the output to your PKI administrator. The PKI organization, the CA, or your PKI administrator then creates certificates. The certificates that the PKI or CA returns to you are input to the certdb subcommand. The certificate revocation list (CRL) that the PKI returns to you is input for the certrldb subcommand.

ikecert certdb Command

The certdb subcommand manages the public key database. Options to this subcommand enable you to add, view, and remove certificates and public keys. The command accepts, as input, certificates that were generated by the ikecert certlocal -ks command on a remote system. For the procedure, see How to Configure IKE With Self-Signed Public Key Certificates. This command also accepts the certificate that you receive from a PKI or CA as input. For the procedure, see How to Configure IKE With Certificates Signed by a CA.

The certificates and public keys are stored on the system in the /etc/inet/ike/publickeys directory. The -T option stores the certificates, private keys, and public keys on attached hardware.

ikecert certrldb Command

The certrldb subcommand manages the certificate revocation list (CRL) database, /etc/inet/ike/crls. The CRL database maintains the revocation lists for public keys. Certificates that are no longer valid are on this list. When PKIs provide you with a CRL, you can install the CRL in the CRL database with the ikecert certrldb command. For the procedure, see How to Handle a Certificate Revocation List.

/etc/inet/ike/publickeys Directory

The /etc/inet/ike/publickeys directory contains the public part of a public-private key pair and its certificate in files, or slots. The directory is protected at 0755. The ikecert certdb command populates the directory. The -T option stores the keys on the Sun Crypto Accelerator 6000 or Sun Crypto Accelerator 4000 board rather than in the publickeys directory.

The slots contain, in encoded form, the X.509 distinguished name of a certificate that was generated on another system. If you are using self-signed certificates, you use the certificate that you receive from the administrator of the remote system as input to the command. If you are using certificates from a CA, you install two signed certificates from the CA into this database. You install a certificate that is based on the certificate signing request that you sent to the CA. You also install a certificate of the CA.

/etc/inet/secret/ike.privatekeys Directory

The /etc/inet/secret/ike.privatekeys directory holds private key files that are part of a public-private key pair, which is keying material for ISAKMP SAs. The directory is protected at 0700. The ikecert certlocal command populates the ike.privatekeys directory. Private keys are not effective until their public key counterparts, self-signed certificates or CAs, are installed. The public key counterparts are stored in the /etc/inet/ike/publickeys directory or on a Sun Crypto Accelerator 6000 or Sun Crypto Accelerator 4000 board.

/etc/inet/ike/crls Directory

The /etc/inet/ike/crls directory contains certificate revocation list (CRL) files. Each file corresponds to a public certificate file in the /etc/inet/ike/publickeys directory. PKI organizations provide the CRLs for their certificates. You can use the ikecert certrldb command to populate the database.

Chapter 25 Oracle Solaris IP Filter (Overview)

This chapter provides an overview of Oracle Solaris IP Filter. For Oracle Solaris IP Filter tasks, see Chapter 26, Oracle Solaris IP Filter (Tasks).

This chapter contains the following information:

What's New in Oracle Solaris IP Filter

This section describes new Oracle Solaris IP Filter features.

For a complete listing of new features and a description of Oracle Solaris releases, see Oracle Solaris 10 9/10 What’s New

Packet Filter Hooks

Beginning with the Solaris 10 7/07 release: Packet filter hooks are now used for packet filtering in Oracle Solaris. This feature offers the following advantages in system administration:

For further details about these hooks, see Packet Filter Hooks. For tasks that are associated with packet filter hooks, see Chapter 26, Oracle Solaris IP Filter (Tasks).

IPv6 Packet Filtering for Oracle Solaris IP Filter

Solaris 10 6/06: For system administrators who have all or part of their network infrastructure configured with IPv6, Oracle Solaris IP Filter has been enhanced to include IPv6 packet filtering. IPv6 packet filtering can filter based on the source/destination IPv6 address, pools containing IPv6 addresses, and IPv6 extension headers.

The -6 option has been added to both the ipf command and the ipfstat command to use with IPv6. Although there is no change to the command line interface for the ipmon and ippool commands, these commands also support IPv6. The ipmon command has been enhanced to accommodate the logging of IPv6 packets, and the ippool command supports the inclusion of IPv6 addresses in pools.

For more information see IPv6 for Oracle Solaris IP Filter. For tasks associated with IPv6 packet filtering, see Chapter 26, Oracle Solaris IP Filter (Tasks).

Introduction to Oracle Solaris IP Filter

Oracle Solaris IP Filter replaces the SunScreen firewall as the firewall software for Oracle Solaris. Like the SunScreen firewall, Oracle Solaris IP Filter provides stateful packet filtering and network address translation (NAT). Oracle Solaris IP Filter also includes stateless packet filtering and the ability to create and manage address pools.

Packet filtering provides basic protection against network-based attacks. Oracle Solaris IP Filter can filter by IP address, port, protocol, network interface, and traffic direction. Oracle Solaris IP Filter can also filter by an individual source IP address, a destination IP address, by a range of IP addresses, or by address pools.

Oracle Solaris IP Filter is derived from open source IP Filter software. To view license terms, attribution, and copyright statements for open source IP Filter, the default path is /usr/lib/ipf/IPFILTER.LICENCE. If Oracle Solaris has been installed anywhere other than the default, modify the given path to access the file at the installed location.

Information Sources for Open Source IP Filter

The home page for the open source IP Filter software by Darren Reed is found at http://coombs.anu.edu.au/~avalon/ip-filter.html. This site includes information for open source IP Filter, including a link to a tutorial entitled “IP Filter Based Firewalls HOWTO” (Brendan Conoboy and Erik Fichtner, 2002). This tutorial provides step-by-step instructions for building firewalls in a BSD UNIX environment. Although written for a BSD UNIX environment, the tutorial is also relevant for the configuration of Oracle Solaris IP Filter.

Oracle Solaris IP Filter Packet Processing

Oracle Solaris IP Filter executes a sequence of steps as a packet is processed. The following diagram illustrates the steps of packet processing and how filtering integrates with the TCP/IP protocol stack.

Figure 25–1 Packet Processing Sequence

Shows the sequence of steps associated with Oracle Solaris IP Filter packet processing.

The packet processing sequence includes the following:

Guidelines for Using OpenSolaris IP Filter

Using Oracle Solaris IP Filter Configuration Files

Oracle Solaris IP Filter can be used to provide firewall services or network address translation (NAT). Oracle Solaris IP Filter can be implemented using loadable configuration files. Oracle Solaris IP Filter includes a directory called /etc/ipf. You can create and store configuration files called ipf.conf, ipnat.conf and ippool.conf in the /etc/ipf directory. These files are loaded automatically during the boot process when they reside in the /etc/ipf directory. You can also store the configuration files in another location and load the files manually. For example configuration files, see Creating and Editing Oracle Solaris IP Filter Configuration Files.

Working With Oracle Solaris IP Filter Rule Sets

To manage your firewall, you use Oracle Solaris IP Filter to specify rule sets that you use to filter your network traffic. You can create the following types of rule sets:

Additionally, you can create address pools to reference groups of IP addresses. You can then use these pools later in a rule set. The address pools help to speed up rule processing. Address pools also make managing large groups of addresses easier.

Using Oracle Solaris IP Filter's Packet Filtering Feature

You set up packet filtering by using packet filtering rule sets. Use the ipf command to work with packet filtering rule sets. For more information on the ipf command, see the ipf(1M) command.

You can create packet filtering rules either at the command line, using the ipf command, or in a packet filtering configuration file. If you want the packet filtering rules to be loaded at boot time, create a configuration file called /etc/ipf/ipf.conf in which to put packet filtering rules. If you do not want the packet filtering rules loaded at boot time, put the ipf.conf file in a location of your choice, and manually activate packet filtering by using the ipf command.

You can maintain two sets of packet filtering rule sets with Oracle Solaris IP Filter, the active rule set and the inactive rule set. In most cases, you work with the active rule set. However, the ipf -I command enables you to apply the command action to the inactive rule list. The inactive rule list is not used by Oracle Solaris IP Filter unless you select it. The inactive rule list provides you with a place to store rules without affecting active packet filtering.

Oracle Solaris IP Filter processes the rules in the rules list from the beginning of the configured rules list to the end of the rules list before passing or blocking a packet. Oracle Solaris IP Filter maintains a flag that determines whether it will or will not pass a packet. It goes through the entire rule set and determines whether to pass or block the packet based on the last matching rule.

There are two exceptions to this process. The first exception is if the packet matches a rule containing the quick keyword. If a rule includes the quick keyword, the action for that rule is taken, and no subsequent rules are checked. The second exception is if the packet matches a rule containing the group keyword. If a packet matches a group, only rules tagged with the group are checked.

Configuring Packet Filtering Rules

Use the following syntax to create packet filtering rules:

action [in|out] option keyword, keyword...

  1. Each rule begins with an action. Oracle Solaris IP Filter applies the action to the packet if the packet matches the rule. The following list includes the commonly used actions applied to a packet.

    block

    Prevents the packet from passing through the filter.

    pass

    Allows the packet through the filter.

    log

    Logs the packet but does not determine if the packet is blocked or passed. Use the ipmon command to view the log.

    count

    Includes the packet in the filter statistics. Use the ipfstat command to view the statistics.

    skip number

    Makes the filter skip over number filtering rules.

    auth

    Requests that packet authentication be performed by a user program that validates packet information. The program determines whether the packet is passed or blocked.

    preauth

    Requests that the filter look at a pre-authenticated list to determine what to do with the packet.

  2. Following the action, the next word must be either in or out. Your choice determines whether the packet filtering rule is applied to an incoming packet or to an outgoing packet.

  3. Next, you can choose from a list of options. If you use more than one option, they must be in the order shown here.

    log

    Logs the packet if the rule is the last matching rule. Use the ipmon command to view the log.

    quick

    Executes the rule containing the quick option if there is a packet match. All further rule checking stops.

    on interface-name

    Applies the rule only if the packet is moving in or out of the specified interface.

    dup-to interface-name

    Copies the packet and sends the duplicate out on interface-name to an optionally specified IP address.

    to interface-name

    Moves the packet to an outbound queue on interface-name.

  4. After specifying the options, you can choose from a variety of keywords that determine whether the packet matches the rule. The following keywords must be used in the order shown here.

    Note –

    By default, any packet that does not match any rule in the configuration file is passed through the filter.

    tos

    Filters the packet based on the type-of-service value expressed as either a hexadecimal or a decimal integer.

    ttl

    Matches the packet based on its time-to-live value. The time-to-live value stored in a packet indicates the length of time a packet can be on the network before being discarded.

    proto

    Matches a specific protocol. You can use any of the protocol names specified in the /etc/protocols file, or use a decimal number to represent the protocol. The keyword tcp/udp can be used to match either a TCP or a UDP packet.

    from/to/all/any

    Matches any or all of the following: the source IP address, the destination IP address, and the port number. The all keyword is used to accept packets from all sources and to all destinations.

    with

    Matches specified attributes associated with the packet. Insert either the word not or the word no in front of the keyword in order to match the packet only if the option is not present.

    flags

    Used for TCP to filter based on TCP flags that are set. For more information on the TCP flags, see the ipf(4) man page.

    icmp-type

    Filters according to ICMP type. This keyword is used only when the proto option is set to icmp and is not used if the flags option is used.

    keep keep-options

    Determines the information that is kept for a packet. The keep-options available include the state option and the frags option. The state option keeps information about the session and can be kept on TCP, UDP, and ICMP packets. The frags option keeps information on packet fragments and applies the information to later fragments. The keep-options allow matching packets to pass without going through the access control list.

    head number

    Creates a new group for filtering rules, which is denoted by the number number.

    group number

    Adds the rule to group number number instead of the default group. All filtering rules are placed in group 0 if no other group is specified.

The following example illustrates how to put together the packet filtering rule syntax to create a rule. To block incoming traffic from the IP address 192.168.0.0/16, you would include the following rule in the rule list:


block in quick from 192.168.0.0/16 to any

For the complete grammar and syntax used to write packet filtering rules, see the ipf(4) man page. For tasks associated with packet filtering, see Managing Packet Filtering Rule Sets for Oracle Solaris IP Filter. For an explanation of the IP address scheme (192.168.0.0/16) shown in the example, see Chapter 2, Planning Your TCP/IP Network (Tasks).

Using Oracle Solaris IP Filter's NAT Feature

NAT sets up mapping rules that translate source and destination IP addresses into other Internet or intranet addresses. These rules modify the source and destination addresses of incoming or outgoing IP packets and send the packets on. You can also use NAT to redirect traffic from one port to another port. NAT maintains the integrity of the packet during any modification or redirection done on the packet.

Use the ipnat command to work with NAT rule lists. For more information on the ipnat command, see the ipnat(1M) command.

You can create NAT rules either at the command line, using the ipnat command, or in a NAT configuration file. NAT configuration rules reside in the ipnat.conf file. If you want the NAT rules to be loaded at boot time, create a file called /etc/ipf/ipnat.conf in which to put NAT rules. If you do not want the NAT rules loaded at boot time, put the ipnat.conf file in a location of your choice, and manually activate packet filtering with the ipnat command.

Configuring NAT Rules

Use the following syntax to create NAT rules:

command interface-name parameters

  1. Each rule begins with one of the following commands:

    map

    Maps one IP address or network to another IP address or network in an unregulated round-robin process.

    rdr

    Redirects packets from one IP address and port pair to another IP address and port pair.

    bimap

    Establishes a bidirectional NAT between an external IP address and an internal IP address.

    map-block

    Establishes static IP address-based translation. This command is based on an algorithm that forces addresses to be translated into a destination range.

  2. Following the command, the next word is the interface name, such as hme0.

  3. Next, you can choose from a variety of parameters, which determine the NAT configuration. Some of the parameters include:

    ipmask

    Designates the network mask.

    dstipmask

    Designates the address that ipmask is translated to.

    mapport

    Designates tcp, udp, or tcp/udp protocols, along with a range of port numbers.

The following example illustrates how to put together the NAT rule syntax together to create a NAT rule. To rewrite a packet that goes out on the de0 device with a source address of 192.168.1.0/24 and to externally show its source address as 10.1.0.0/16, you would include the following rule in the NAT rule set:


map de0 192.168.1.0/24 -> 10.1.0.0/16

For the complete grammar and syntax used to write NAT rules, see the ipnat(4) man page.

Using Oracle Solaris IP Filter's Address Pools Feature

Address pools establish a single reference that is used to name a group of address/netmask pairs. Address pools provide processes to reduce the time needed to match IP addresses with rules. Address pools also make managing large groups of addresses easier.

Address pool configuration rules reside in the ippool.conf file. If you want the address pool rules to be loaded at boot time, create a file called /etc/ipf/ippool.conf in which to put address pool rules. If you do not want the address pool rules loaded at boot time, put the ippool.conf file in a location of your choice, and manually activate packet filtering with the ippool command.

Configuring Address Pools

Use the following syntax to create an address pool:


table role = role-name type = storage-format number = reference-number
table

Defines the reference for the multiple addresses.

role

Specifies the role of the pool in Oracle Solaris IP Filter. At this time, the only role you can reference is ipf.

type

Specifies the storage format for the pool.

number

Specifies the reference number that is used by the filtering rule.

For example, to reference the group of addresses 10.1.1.1 and 10.1.1.2, and the network 192.16.1.0 as pool number 13, you would include the following rule in the address pool configuration file:

table role = ipf type = tree number = 13 
{ 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 };

Then, to reference pool number 13 in a filtering rule, you would construct the rule similar to the following example:


pass in from pool/13 to any

Note that you must load the pool file before loading the rules file that contains a reference to the pool. If you do not, the pool is undefined, as shown in the following output:


# ipfstat -io
empty list for ipfilter(out)
block in from pool/13(!) to any

Even if you add the pool later, the addition of the pool does not update the kernel rule set. You also need to reload the rules file that references the pool.

For the complete grammar and syntax used to write packet filtering rules, see the ippool(4) man page.

Packet Filter Hooks

Beginning with the Solaris 10 7/07 release, packet filter hooks replace the pfil module to enable Oracle Solaris IP filter. In previous Oracle Solaris releases, configuration of the pfil module was required as an additional step to set up Oracle Solaris IP Filter. This extra configuration requirement increased the risk of errors that would cause Oracle Solaris IP Filter to work improperly. The insertion of the pfil STREAMS module between IP and the device driver also caused performance degradation. Lastly, the pfil module could not perform packet interception between zones.

The use of packet filter hooks streamlines the procedure to enable Oracle Solaris IP Filter. Through these hooks, Oracle Solaris IP Filter uses pre-routing (input) and post-routing (output) filter taps to control packet flow into and out of the Oracle Solaris system.

Packet filter hooks eliminate the need for the pfil module. Thus the following components that are associated with the module are also removed.

For tasks associated with enabling Oracle Solaris IP Filter, see Chapter 26, Oracle Solaris IP Filter (Tasks).

Oracle Solaris IP Filter and the pfil STREAMS Module

Note –

The pfil module is used with Oracle Solaris IP filter only on the following Oracle Solaris 10 releases:

Beginning with the Solaris 10 7/07 release, the pfil module has been replaced by packet filter hooks and is no longer used with Oracle Solaris IP filter.

The pfil STREAMS module is required to enable Oracle Solaris IP Filter. However, Oracle Solaris IP Filter does not provide an automatic mechanism to push the module on to every interface. Instead, the pfil STREAMS module is managed by the SMF service svc:/network/pfil. To activate filtering on a network interface, you first configure the pfil.ap file. Then you activate the svc:/network/pfil service to supply the pfil STREAMS module to the network interface. For the STREAMS module to take effect, the system must be rebooted or each network interface on which you want filtering must be unplumbed and then re-plumbed. To activate IPv6 packet filtering capabilities, you need to plumb the inet6 version of the interface.

If no pfil modules are found for the network interfaces, the SMF services are put into a maintenance state. The most common cause of this situation is an incorrectly edited /etc/ipf/pfil.ap file. If the service is put into maintenance mode, the occurrence is logged in the filtering log files.

For tasks associated with activating Oracle Solaris IP Filter, see Configuring Oracle Solaris IP Filter.

IPv6 for Oracle Solaris IP Filter

Beginning with the Solaris 10 6/06 release, support for IPv6 is available with Oracle Solaris IP Filter. IPv6 packet filtering can filter based on the source/destination IPv6 address, pools containing IPv6 addresses, and IPv6 extension headers.

IPv6 is similar to IPv4 in many ways. However, header and packet size differ between the two versions of IP, which is an important consideration for IP Filter. IPv6 packets known as jumbograms contain a datagram longer than 65,535 bytes. Oracle Solaris IP Filter does not support IPv6 jumbograms. To learn more about other IPv6 features, see Major Features of IPv6.

Note –

For more information on jumbograms, refer to the document IPv6 Jumbograms, RFC 2675 from the Internet Engineering Task Force (IETF). [http://www.ietf.org/rfc/rfc2675.txt]

IP Filter tasks associated with IPv6 do not differ substantially from IPv4. The most notable difference is the use of the -6 option with certain commands. Both the ipf command and the ipfstat command include the -6 option for use with IPv6 packet filtering. Use the -6 option with the ipf command to load and flush IPv6 packet filtering rules. To display IPv6 statistics, use the -6 option with the ipfstat command. The ipmon and ippool commands also support IPv6, although there is no associated option for IPv6 support. The ipmon command has been enhanced to accommodate the logging of IPv6 packets. The ippool command supports the pools with IPv6 addresses. You can create pools of only IPv4 or IPv6 addresses, or a pool containing both IPv4 and IPv6 addresses within the same pool.

You can use the ipf6.conf file to create packet filtering rule sets for IPv6. By default, the ipf6.conf configuration file is included in the /etc/ipf directory. As with the other filtering configuration files, the ipf6.conf file loads automatically during the boot process when it is stored in the /etc/ipf directory. You can also create and store an IPv6 configuration file in another location and load the file manually.

Note –

Network Address Translation (NAT) does not support IPv6.

Once packet filtering rules for IPv6 have been set up, activate IPv6 packet filtering capabilities by plumbing the inet6 version of the interface.

For more information on IPv6, see Chapter 3, Introducing IPv6 (Overview). For tasks associated with Oracle Solaris IP Filter, see Chapter 26, Oracle Solaris IP Filter (Tasks).

Oracle Solaris IP Filter Man Pages

The following table includes the man page documentation relevant to Oracle Solaris IP Filter.

Man Page 

Description 

ipf(1M)

Use the ipf command to complete the following tasks:

  • Work with packet filtering rule sets.

  • Disable and enable filtering.

  • Reset statistics and resynchronize the in-kernel interface list with the current interface status list.

ipf(4)

Contains the grammar and syntax for creating Oracle Solaris IP Filter packet filtering rules. 

ipfilter(5)

Provides open source IP Filter licensing information. 

ipfs(1M)

Use the ipfs command to save and restore NAT information and state table information across reboots.

ipfstat(1M)

Use the ipfstat command to retrieve and display statistics on packet processing.

ipmon(1M)

Use the ipmon command to open the log device and view logged packets for both packet filtering and NAT.

ipnat(1M)

Use the ipnat command to complete the following tasks:

  • Work with NAT rules.

  • Retrieve and display NAT statistics.

ipnat(4)

Contains the grammar and syntax for creating NAT rules. 

ippool(1M)

Use the ippool command to create and manage address pools.

ippool(4)

Contains the grammar and syntax for creating Oracle Solaris IP Filter address pools. 

ndd(1M)

Displays current filtering parameters of the pfil STREAMS module and the current values of the tunable parameters.

Chapter 26 Oracle Solaris IP Filter (Tasks)

This chapter provides step-by-step instructions for Solaris IP Filter tasks. For overview information about Oracle Solaris IP Filter, see Chapter 25, Oracle Solaris IP Filter (Overview).

This chapter contains the following information:

Configuring Oracle Solaris IP Filter

The following task map identifies the procedures associated with configuring Oracle Solaris IP Filter.

Table 26–1 Configuring Oracle Solaris IP Filter (Task Map)

Task 

Description 

For Instructions 

Initially enable Oracle Solaris IP Filter. 

Oracle Solaris IP Filter is not enabled by default. You must either enable it manually or use the configuration files in the /etc/ipf/ directory and reboot the system. Beginning with the Solaris 10 7/07 release, packet filter hooks replaced the pfil module to enable Oracle Solaris IP filter.

How to Enable Oracle Solaris IP Filter

Re-enable Oracle Solaris IP Filter. 

If Oracle Solaris IP Filter is deactivated or disabled, you can re-enable Oracle Solaris IP Filter either by rebooting the system or by using the ipf command.

How to Re-Enable Oracle Solaris IP Filter

Enable loopback filtering 

As an option, you can enable loopback filtering, for example, to filter traffic between zones. 

How to Enable Loopback Filtering

ProcedureHow to Enable Oracle Solaris IP Filter

Use this procedure to enable Oracle Solaris IP Filter on a system that is running at least Solaris 10 7/07 OS. To enable Oracle Solaris IP Filters if your system is running Oracle Solaris 10 previous to Solaris 10 7/07 OS, see Working With the pfil Module.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Create a packet filtering rule set.

    The packet filtering rule set contains packet filtering rules that are used by Oracle Solaris IP Filter. If you want the packet filtering rules to be loaded at boot time, edit the /etc/ipf/ipf.conf file to implement IPv4 packet filtering. Use the /etc/ipf/ipf6.conf file for IPv6 packet filtering rules. If you do not want the packet filtering rules loaded at boot time, put the rules in a file of your choice, and manually activate packet filtering. For information about packet filtering, see Using Oracle Solaris IP Filter's Packet Filtering Feature. For information about working with configuration files, see Creating and Editing Oracle Solaris IP Filter Configuration Files.

  3. (Optional) Create a network address translation (NAT) configuration file.

    Note –

    Network Address Translation (NAT) does not support IPv6.

    Create an ipnat.conf file if you want to use network address translation. If you want the NAT rules to be loaded at boot time, create a file called /etc/ipf/ipnat.conf in which to put NAT rules. If you do not want the NAT rules loaded at boot time, put the ipnat.conf file in a location of your choice, and manually activate the NAT rules.

    For more information about NAT, see Using Oracle Solaris IP Filter's NAT Feature.

  4. (Optional) Create an address pool configuration file.

    Create an ipool.conf file if you want to refer to a group of addresses as a single address pool. If you want the address pool configuration file to be loaded at boot time, create a file called /etc/ipf/ippool.conf in which to put the address pool. If you do not want the address pool configuration file to be loaded at boot time, put the ippool.conf file in a location of your choice, and manually activate the rules.

    An address pool can contain only IPv4 addresses or only IPv6 addresses. It can also contain both IPv4 and IPv6 addresses.

    For more information about address pools, see Using Oracle Solaris IP Filter's Address Pools Feature.

  5. (Optional) Enable filtering of loopback traffic.

    If you intend to filter traffic between zones that are configured in your system, you must enable loopback filtering. See How to Enable Loopback Filtering. Make sure that you also define the appropriate rule sets that apply to the zones.

  6. Activate Oracle Solaris IP Filter.


    # svcadm enable network/ipfilter

ProcedureHow to Re-Enable Oracle Solaris IP Filter

You can re-enable packet filtering after it has been temporarily disabled.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Enable Oracle Solaris IP Filter and activate filtering using one of the following methods:

    • Reboot the machine.


      # reboot
      Note –

      When IP Filter is enabled, after a reboot the following files are loaded if they are present: the /etc/ipf/ipf.conf file, the /etc/ipf/ipf6.conf file when using IPv6, or the /etc/ipf/ipnat.conf.

    • Perform the following series of commands to enable Oracle Solaris IP Filter and activate filtering:

      1. Enable Oracle Solaris IP Filter.


        # ipf -E

      2. Activate packet filtering.


        # ipf -f filename

      3. (Optional) Activate NAT.


        # ipnat -f filename
        Note –

        Network Address Translation (NAT) does not support IPv6.

ProcedureHow to Enable Loopback Filtering

Note –

You can filter loopback traffic only if your system is running at least Solaris 10 7/07 release. In previous Oracle Solaris 10 releases, loopback filtering is not supported.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Stop Oracle Solaris IP Filter if it is running.


    # svcadm disable network/ipfilter

  3. Edit the /etc/ipf.conf or /etc/ipf6.conf file by adding the following line at the beginning of the file:


    set intercept_loopback true;

    This line must precede all the IP filter rules that are defined in the file. However, you can insert comments before the line, similar to the following example:


    # 
# Enable loopback filtering to filter between zones 
# 
set intercept_loopback true; 
# 
# Define policy 
# 
block in all 
block out all 
<other rules>
...

  4. Start the Oracle Solaris IP filter.


    # svcadm enable network/ipfilter

  5. To verify the status of loopback filtering, use the following command:


    # ipf —T ipf_loopback
ipf_loopback    min 0   max 0x1 current 1
#

    If loopback filtering is disabled, the command would generate the following output:


    ipf_loopback    min 0   max 0x1 current 0

Deactivating and Disabling Oracle Solaris IP Filter

You might want to deactivate or disable packet filtering and NAT under the following circumstances:

The following task map identifies the procedures associated with deactivating or disabling Oracle Solaris IP Filter features.

Table 26–2 Deactivating and Disabling Oracle Solaris IP Filter (Task Map)

Task 

Description 

For Instructions 

Deactivate packet filtering. 

Deactivate packet filtering using the ipf command.

How to Deactivate Packet Filtering

Deactivate NAT. 

Deactivate NAT using the ipnat command.

How to Deactivate NAT

Disable packet filtering and NAT. 

Disable packet filtering and NAT using the ipf command.

How to Disable Packet Filtering

ProcedureHow to Deactivate Packet Filtering

The following procedure deactivates Oracle Solaris IP Filter packet filtering by flushing the packet filtering rules from the active filtering rule set. The procedure does not disable Oracle Solaris IP Filter. You can reactivate Oracle Solaris IP Filter by adding rules to the rule set.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Use one of the following methods to deactivate Oracle Solaris IP Filter rules:

    • Remove the active rule set from the kernel.


      # ipf -Fa

      This command deactivates all packet filtering rules.

    • Remove incoming packet filtering rules.


      # ipf -Fi

      This command deactivates packet filtering rules for incoming packets.

    • Remove outgoing packet filtering rules.


      # ipf -Fo

      This command deactivates packet filtering rules for outgoing packets.

ProcedureHow to Deactivate NAT

The following procedure deactivates Oracle Solaris IP Filter NAT rules by flushing the NAT rules from the active NAT rules set. The procedure does not disable Oracle Solaris IP Filter. You can reactivate Oracle Solaris IP Filter by adding rules to the rule set.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Remove NAT from the kernel.


    # ipnat -FC

    The -C option removes all entries in the current NAT rule listing. The -F option removes all active entries in the current NAT translation table, which shows the currently active NAT mappings.

ProcedureHow to Disable Packet Filtering

When you run this procedure, both packet filtering and NAT are removed from the kernel. If you use this procedure, you must re-enable Solaris IP Filter in order to reactivate packet filtering and NAT. For more information, see How to Re-Enable Oracle Solaris IP Filter.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Disable packet filtering and allow all packets to pass into the network.


    # ipf –D
    Note –

    The ipf -D command flushes the rules from the rule set. When you re-enable filtering, you must add rules to the rule set.

Working With the pfil Module

This section describes how to use the pfil STREAMS module to activate or deactivate Oracle Solaris IP Filter and how to view pfil statistics. The procedures apply only to systems that run one of the followingOracle Solaris 10 releases:

The following task map identifies procedures that are associated with configuring the pfil module.

Table 26–3 Working With the pfil Module (Task Map)

Task 

Description 

For Instructions 

Enable Oracle Solaris IP Filter 

Oracle Solaris IP Filter is not enabled by default. You must either enable it manually or use the configuration files in the /etc/ipf/ directory and reboot the system.

How to Enable Oracle Solaris IP Filter in Previous Oracle Solaris 10 Releases

Activate a NIC for packet filtering 

Configure the pfil module to activate packet filtering on a NIC

How to Activate a NIC for Packet Filtering

Deactivate Oracle Solaris IP Filter on a NIC 

Remove a NIC and allow all packets to pass through the NIC. 

How to Deactivate Oracle Solaris IP Filter on a NIC

View pfil statistics.

View statistics for the pfil module to help you troubleshoot Oracle Solaris IP Filter using the ndd command.

How to View pfil Statistics for Oracle Solaris IP Filter

ProcedureHow to Enable Oracle Solaris IP Filter in Previous Oracle Solaris 10 Releases

Oracle Solaris IP Filter is installed with Oracle Solaris. However, packet filtering is not enabled by default. Use the following procedure to activate Oracle Solaris IP Filter.

Note –

If your system is running at least the Solaris 10 7/07 release, follow the procedure How to Enable Oracle Solaris IP Filter that uses packet filter hooks.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Start the file editor of your choice, and edit the /etc/ipf/pfil.ap file.

    This file contains the names of network interface cards (NICs) on the host. By default, the names are commented out. Uncomment the device names that carry the network traffic you want to filter. If the name of the NIC for your system is not listed, add a line to specify the NIC.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Activate your changes to the /etc/ipf/pfil.ap file by restarting the network/pfil service instance.


    # svcadm restart network/pfil

  4. Create a packet filtering rule set.

    The packet filtering rule set contains packet filtering rules that are used by Oracle Solaris IP Filter. If you want the packet filtering rules to be loaded at boot time, edit the /etc/ipf/ipf.conf file to implement IPv4 packet filtering. Use the /etc/ipf/ipf6.conf file for IPv6 packet filtering rules. If you do not want the packet filtering rules loaded at boot time, put the rules in a file of your choice, and manually activate packet filtering. For information about packet filtering, see Using Oracle Solaris IP Filter's Packet Filtering Feature. For information about working with configuration files, see Creating and Editing Oracle Solaris IP Filter Configuration Files.

  5. (Optional) Create a network address translation (NAT) configuration file.

    Note –

    Network Address Translation (NAT) does not support IPv6.

    Create an ipnat.conf file if you want to use network address translation. If you want the NAT rules to be loaded at boot time, create a file called /etc/ipf/ipnat.conf in which to put NAT rules. If you do not want the NAT rules loaded at boot time, put the ipnat.conf file in a location of your choice, and manually activate the NAT rules.

    For more information about NAT, see Using Oracle Solaris IP Filter's NAT Feature.

  6. (Optional) Create an address pool configuration file.

    Create an ipool.conf file if you want to refer to a group of addresses as a single address pool. If you want the address pool configuration file to be loaded at boot time, create a file called /etc/ipf/ippool.conf in which to put the address pool. If you do not want the address pool configuration file to be loaded at boot time, put the ippool.conf file in a location of your choice, and manually activate the rules.

    An address pool can contain only IPv4 addresses or only IPv6 addresses. It can also contain both IPv4 and IPv6 addresses.

    For more information about address pools, see Using Oracle Solaris IP Filter's Address Pools Feature.

  7. Activate Oracle Solaris IP Filter by using one of the following methods:

    • Enable IP Filter and reboot the machine.


      # svcadm enable network/ipfilter
# reboot
      Note –

      Rebooting is required if you cannot safely use the ifconfig unplumb and ifconfig plumb commands on the NICs.

    • Enable the NICs by using the ifconfig unplumb and ifconfig plumb commands. Then enable IP Filter. The inet6 version of the interface must be plumbed in order to implement IPv6 packet filtering.


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up
# ifconfig hme0 inte6 unplumb
# ifconfig hme0 inet6 plumb fec3:f849::1/96 up
# svcadm enable network/ipfilter

      For more information about the ifconfig command, see the ifconfig(1M) man page.

ProcedureHow to Activate a NIC for Packet Filtering

Oracle Solaris IP Filter is enabled at boot time when the /etc/ipf/ipf.conf file (or the /etc/ipf/ipf6.conf file when using IPv6) exists. If you need to enable filtering on a NIC after Oracle Solaris IP Filter is enabled, use the following procedure.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Start the file editor of your choice, and edit the /etc/ipf/pfil.ap file.

    This file contains the names of NICs on the host. By default, the names are commented out. Uncomment the device names that carry the network traffic you want to filter. If the name of the NIC for your system is not listed, add a line to specify the NIC.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Activate your changes to the /etc/ipf/pfil.ap file by restarting the network/pfil service instance.


    # svcadm restart network/pfil

  4. Enable the NIC by using one of the following methods:

    • Reboot the machine.


      # reboot
      Note –

      Rebooting is required if you cannot safely use the ifconfig unplumb and ifconfig plumb commands on the NICs.

    • Enable the NICs that you want to filter by using the ifconfig command with the unplumb and plumb options. The inet6 version of each interface must be plumbed in order to implement IPv6 packet filtering.


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

      For more information about the ifconfig command, see the ifconfig(1M) man page.

ProcedureHow to Deactivate Oracle Solaris IP Filter on a NIC

If you need to stop filtering packets on a NIC, use the following procedure.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Start the file editor of your choice, and edit the /etc/ipf/pfil.ap file.

    This file contains the names of NICs on the host. The NICs that have been used to filter network traffic are uncommented. Comment out the device names that you no longer want to use to filter network traffic.


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
#hme    -1      0       pfil (Commented-out device no longer filters network traffic)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. Deactivate the NIC by using one of the following methods:

    • Reboot the machine.


      # reboot
      Note –

      Rebooting is required if you cannot safely use the ifconfig unplumb and ifconfig plumb commands on the NICs.

    • Deactivate the NICs by using the ifconfig command with the unplumb and plumb options. The inet6 version of each interface must be unplumbed in order to deactivate IPv6 packet filtering. Perform the following steps. The sample device in the system is hme:

      1. Identify the major number for the device you are deactivating.


        # grep hme /etc/name_to_major
hme 7

      2. Display the current autopush configuration for hme0. 


        # autopush -g -M 7 -m 0
   Major     Minor     Lastminor       Modules
       7      ALL          -           pfil

      3. Remove the autopush configuration.


        # autopush -r -M 7 -m 0

      4. Open the device and assign IP addresses to the device.


        # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

        For more information about the ifconfig command, see the ifconfig(1M) man page.

ProcedureHow to View pfil Statistics for Oracle Solaris IP Filter

You can view pfil statistics when you are troubleshooting Oracle Solaris IP Filter.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View pfil statistics.


    # ndd -get /dev/pfil qif_status
Example 26–1 Viewing pfil Statistics for Oracle Solaris IP Filter

The following example shows how to view pfil statistics.


# ndd -get /dev/pfil qif_status
ifname ill q OTHERQ num sap hl nr nw bad copy copyfail drop notip nodata
   notdata
QIF6 0 300011247b8 300011248b0 6 806 0 4 9 0 0 0 0 0 0 0
dmfe1 3000200a018 30002162a50 30002162b48 5 800 14 171 13681 0 0 0 0 0 0 0

Working With Oracle Solaris IP Filter Rule Sets

The following task map identifies the procedures associated with Oracle Solaris IP Filter rule sets.

Table 26–4 Working With Oracle Solaris IP Filter Rule Sets (Task Map)

Task 

Description 

For Instructions 

Manage, view and modify Oracle Solaris IP Filter packet filtering rule sets. 

 

Managing Packet Filtering Rule Sets for Oracle Solaris IP Filter

 

View an active packet filtering rule set. 

How to View the Active Packet Filtering Rule Set

 

View an inactive packet filtering rule set. 

How to View the Inactive Packet Filtering Rule Set

 

Activate a different active rule set. 

How to Activate a Different or Updated Packet Filtering Rule Set

 

Remove a rule set. 

How to Remove a Packet Filtering Rule Set

 

Add rules to the rule sets. 

How to Append Rules to the Active Packet Filtering Rule Set

How to Append Rules to the Inactive Packet Filtering Rule Set

 

Move between active and inactive rule sets. 

How to Switch Between Active and Inactive Packet Filtering Rule Sets

 

Delete an inactive rule set from the kernel. 

How to Remove an Inactive Packet Filtering Rule Set From the Kernel

Manage, view and modify Oracle Solaris IP Filter NAT rules. 

 

Managing NAT Rules for Oracle Solaris IP Filter

 

View active NAT rules. 

How to View Active NAT Rules

 

Remove NAT rules. 

How to Remove NAT Rules

 

Add additional rules to NAT rules. 

How to Append Rules to the NAT Rules

Manage, view and modify Oracle Solaris IP Filter address pools. 

 

Managing Address Pools for Oracle Solaris IP Filter

 

View active address pools. 

How to View Active Address Pools

 

Remove an address pool. 

How to Remove an Address Pool

 

Add additional rules to an address pool. 

How to Append Rules to an Address Pool

Managing Packet Filtering Rule Sets for Oracle Solaris IP Filter

When Solaris IP Filter is enabled, both active and inactive packet filtering rule sets can reside in the kernel. The active rule set determines what filtering is being done on incoming packets and outgoing packets. The inactive rule set also stores rules. These rules are not used unless you make the inactive rule set the active rule set. You can manage, view, and modify both active and inactive packet filtering rule sets.

ProcedureHow to View the Active Packet Filtering Rule Set

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the active packet filtering rule set that is loaded in the kernel.


    # ipfstat -io
Example 26–2 Viewing the Active Packet Filtering Rule Set

The following example shows output from the active packet filtering rule set that is loaded in the kernel.


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe1 from 192.168.1.0/24 to any
pass in all
block in on dmfe1 from 192.168.1.10/32 to any

ProcedureHow to View the Inactive Packet Filtering Rule Set

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the inactive packet filtering rule set.


    # ipfstat -I -io
Example 26–3 Viewing the Inactive Packet Filtering Rule Set

The following example shows output from the inactive packet filtering rule set.


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all

ProcedureHow to Activate a Different or Updated Packet Filtering Rule Set

Use the following procedure if you want to perform either of the following tasks:

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Choose one of the following steps:

    • Create a new rule set in a separate file of your choice if you want to activate an entirely different rule set.

    • Update the current rule set by editing the configuration file that contains that rule set.

  3. Remove the current rule set and load the new rule set.


    # ipf -Fa -f filename

    The filename can either be the new file with the new rule set or the updated file that contains the active rule set.

    The active rule set is removed from the kernel. The rules in the filename file become the active rule set.

    Note –

    You still need to issue the command even if you are reloading the current configuration file. Otherwise, the old rule set continues to be operative, and the modified rule set in the updated configuration file is not applied.

    Do not use commands such as ipf -D or svcadm restart to load the updated rule set. Such commands expose your network by disabling the firewall first before loading the new rule set.

Example 26–4 Activating a Different Packet Filtering Rule Set

The following example shows how to replace one packet filtering rule set with another packet filtering rule set in a separate configuration file, /etc/ipf/ipf.conf.


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe all
# ipf -Fa -f /etc/ipf/ipf.conf
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
Example 26–5 Reloading an Updated Packet Filtering Rule Set

The following example shows how to reload a packet filtering rule set that is currently active and which is then updated. In this example, the file in use is /etc/ipf/ipf.conf.


# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any

(Edit the /etc/ipf/ipf.conf configuration file.)

# ip -Fa -f /etc/ipf/ipf.conf
# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any
block in quick on elx10 from 192.168.0.0/12 to any

ProcedureHow to Remove a Packet Filtering Rule Set

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Remove the rule set.


    # ipf -F [a|i|o]
    -a

    Removes all filtering rules from the rule set.

    -i

    Removes the filtering rules for incoming packets.

    -o

    Removes the filtering rules for outgoing packets.

Example 26–6 Removing a Packet Filtering Rule Set

The following example shows how to remove all filtering rules from the active filtering rule set.


# ipfstat -io
block out log on dmf0 all
block in log quick from 10.0.0.0/8 to any
# ipf -Fa
# ipfstat -io
empty list for ipfilter(out)
empty list for ipfilter(in)

ProcedureHow to Append Rules to the Active Packet Filtering Rule Set

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Use one of the following methods to append rules to the active rule set:

    • Append rules to the rule set at the command line using the ipf -f - command.


      # echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -

    • Perform the following commands:

      1. Create a rule set in a file of your choice.

      2. Add the rules you have created to the active rule set.


        # ipf -f filename

        The rules in filename are added to the end of the active rule set. Because Solaris IP Filter uses a “last matching rule” algorithm, the added rules determine filtering priorities, unless you use the quick keyword. If the packet matches a rule containing the quick keyword, the action for that rule is taken, and no subsequent rules are checked.

Example 26–7 Appending Rules to the Active Packet Filtering Rule Set

The following example shows how to add a rule to the active packet filtering rule set from the command line.


# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
# echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any

ProcedureHow to Append Rules to the Inactive Packet Filtering Rule Set

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Create a rule set in a file of your choice.

  3. Add the rules you have created to the inactive rule set.


    # ipf -I -f filename

    The rules in filename are added to the end of the inactive rule set. Because Solaris IP Filter uses a “last matching rule” algorithm, the added rules determine filtering priorities, unless you use the quick keyword. If the packet matches a rule containing the quick keyword, the action for that rule is taken, and no subsequent rules are checked.

Example 26–8 Appending Rules to the Inactive Rule Set

The following example shows how to add a rule to the inactive rule set from a file.


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
# ipf -I -f /etc/ipf/ipf.conf
# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
block in log quick from 10.0.0.0/8 to any

ProcedureHow to Switch Between Active and Inactive Packet Filtering Rule Sets

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Switch the active and inactive rule sets.


    # ipf -s

    This command enables you to switch between the active and inactive rule sets in the kernel. Note that if the inactive rule set is empty, there is no packet filtering.

Example 26–9 Switching Between the Active and Inactive Packet Filtering Rule Sets

The following example shows how using the ipf -s command results in the inactive rule set becoming the active rule set and the active rule set becoming the inactive rule set.

ProcedureHow to Remove an Inactive Packet Filtering Rule Set From the Kernel

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Specify the inactive rule set in the “flush all” command.


    # ipf -I -Fa

    This command flushes the inactive rule set from the kernel.

    Note –

    If you subsequently run ipf -s, the empty inactive rule set will become the active rule set. An empty active rule set means that no filtering will be done.

Example 26–10 Removing an Inactive Packet Filtering Rule Set From the Kernel

The following example shows how to flush the inactive packet filtering rule set so that all rules have been removed.


# ipfstat -I -io
empty list for inactive ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any
# ipf -I -Fa
# ipfstat -I -io
empty list for inactive ipfilter(out)
empty list for inactive ipfilter(in)

Managing NAT Rules for Oracle Solaris IP Filter

Use the following procedures to manage, view, and modify NAT rules.

ProcedureHow to View Active NAT Rules

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the active NAT rules.


    # ipnat -l
Example 26–11 Viewing Active NAT Rules

The following example shows the output from the active NAT rules set.


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

ProcedureHow to Remove NAT Rules

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Remove the current NAT rules.


    # ipnat -C
Example 26–12 Removing NAT Rules

The following example shows how to remove the entries in the current NAT rules.


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:
# ipnat -C
1 entries flushed from NAT list
# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:

ProcedureHow to Append Rules to the NAT Rules

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Use one of the following methods to append rules to the active rule set:

    • Append rules to the NAT rule set at the command line using the ipnat -f - command.


      # echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -

    • Perform the following commands:

      1. Create additional NAT rules in a file of your choice.

      2. Add the rules you have created to the active NAT rules.


        # ipnat -f filename

        The rules in filename are added to the end of the NAT rules.

Example 26–13 Appending Rules to the NAT Rule Set

The following example shows how to add a rule to the NAT rule set from the command line.


# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:
# echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -
# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

Managing Address Pools for Oracle Solaris IP Filter

Use the following procedures to manage, view, and modify address pools.

ProcedureHow to View Active Address Pools

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the active address pool.


    # ippool -l
Example 26–14 Viewing the Active Address Pool

The following example shows how to view the contents of the active address pool.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

ProcedureHow to Remove an Address Pool

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Remove the entries in the current address pool.


    # ippool -F
Example 26–15 Removing an Address Pool

The following example shows how to remove an address pool.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# ippool -F
1 object flushed
# ippool -l

ProcedureHow to Append Rules to an Address Pool

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Use one of the following methods to append rules to the active rule set:

    • Append rules to the rule set at the command line using the ippool -f - command.


      # echo "table role = ipf type = tree number = 13 
{10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24};" | ippool -f -

    • Perform the following commands:

      1. Create additional address pools in a file of your choice.

      2. Add the rules you have created to the active address pool.


        # ippool -f filename

        The rules in filename are added to the end of the active address pool.

Example 26–16 Appending Rules to an Address Pool

The following example shows how to add an address pool to the address pool rule set from the command line.


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# echo "table role = ipf type = tree number = 100
 {10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24};" | ippool -f -
# ippool -l
table role = ipf type = tree number = 100
        { 10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24; };
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

Displaying Statistics and Information for Oracle Solaris IP Filter

Table 26–5 Displaying Oracle Solaris IP Filter Statistics and Information (Task Map)

Task 

Description 

For Instructions 

View state tables. 

View state tables to obtain information about packet filtering using the ipfstat command.

How to View State Tables for Oracle Solaris IP Filter

View state statistics. 

View statistics on packet state information using the ipfstat -s command.

How to View State Statistics for Oracle Solaris IP Filter

View NAT statistics. 

View NAT statistics using the ipnat -s command.

How to View NAT Statistics for Oracle Solaris IP Filter

View address pool statistics. 

View address pool statistics using the ippool -s command.

How to View Address Pool Statistics for Oracle Solaris IP Filter

ProcedureHow to View State Tables for Oracle Solaris IP Filter

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the state table.


    # ipfstat
    Note –

    You can use the -t option to view the state table in the top utility format.

Example 26–17 Viewing State Tables for Oracle Solaris IP Filter

The following example shows how to view a state table.


# ipfstat
bad packets:            in 0    out 0
 input packets:         blocked 160 passed 11 nomatch 1 counted 0 short 0
output packets:         blocked 0 passed 13681 nomatch 6844 counted 0 short 0
 input packets logged:  blocked 0 passed 0
output packets logged:  blocked 0 passed 0
 packets logged:        input 0 output 0
 log failures:          input 0 output 0
fragment state(in):     kept 0  lost 0
fragment state(out):    kept 0  lost 0
packet state(in):       kept 0  lost 0
packet state(out):      kept 0  lost 0
ICMP replies:   0       TCP RSTs sent:  0
Invalid source(in):     0
Result cache hits(in):  152     (out):  6837
IN Pullups succeeded:   0       failed: 0
OUT Pullups succeeded:  0       failed: 0
Fastroute successes:    0       failures:       0
TCP cksum fails(in):    0       (out):  0
IPF Ticks:      14341469
Packet log flags set: (0)
        none

ProcedureHow to View State Statistics for Oracle Solaris IP Filter

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the state statistics.


    # ipfstat -s
Example 26–18 Viewing State Statistics for Oracle Solaris IP Filter

The following example shows how to view state statistics.


# ipfstat -s
IP states added:
        0 TCP
        0 UDP
        0 ICMP
        0 hits
        0 misses
        0 maximum
        0 no memory
        0 max bucket
        0 active
        0 expired
        0 closed
State logging enabled

State table bucket statistics:
        0 in use        
        0.00% bucket usage
        0 minimal length
        0 maximal length
        0.000 average length

ProcedureHow to View NAT Statistics for Oracle Solaris IP Filter

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View NAT statistics.


    # ipnat -s
Example 26–19 Viewing NAT Statistics for Oracle Solaris IP Filter

The following example shows how to view NAT statistics.


# ipnat -s
mapped  in      0       out     0
added   0       expired 0
no memory       0       bad nat 0
inuse   0
rules   1
wilds   0

ProcedureHow to View Address Pool Statistics for Oracle Solaris IP Filter

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View address pool statistics.


    # ippool -s
Example 26–20 Viewing Address Pool Statistics for Oracle Solaris IP Filter

The following example shows how to view address pool statistics.


# ippool -s
Pools:  3
Hash Tables:    0
Nodes:  0

Working With Log Files for Oracle Solaris IP Filter

Table 26–6 Working With Oracle Solaris IP Filter Log Files (Task Map)

Task 

Description 

For Instructions 

Create a log file. 

Create a separate Oracle Solaris IP filter log file. 

How to Set Up a Log File for Oracle Solaris IP Filter

View log files. 

View state, NAT, and normal log files using the ipmon command.

How to View Oracle Solaris IP Filter Log Files

Flush the packet log buffer. 

Remove the contents of the packet log buffer using the ipmon -F command.

How to Flush the Packet Log File

Save logged packets to a file. 

Save logged packets to a file for later reference. 

How to Save Logged Packets to a File

ProcedureHow to Set Up a Log File for Oracle Solaris IP Filter

By default, all log information for Oracle Solaris IP Filter is recorded in the syslogd file. You should set up a log file to record Oracle Solaris IP Filter traffic information separately from other data that might be logged in the default log file. Perform the following steps.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Edit the /etc/syslog.conf file by adding the following two lines:


    # Save IPFilter log output to its own file 
local0.debug             /var/log/log-name
    Note –

    On the second line, make sure to use the Tab key, not the Spacebar, to separate local0.debug from /var/log/log-name.

  3. Create the new log file.


    # touch /var/log/log-name

  4. Restart the system-log service.


    # svcadm restart system-log
Example 26–21 Creating a Oracle Solaris IP Filter Log

The following example shows how to create ipmon.log to archive IP filter information.

In /etc/syslog.conf:


# Save IPFilter log output to its own file 
local0.debug             /var/log/ipmon.log

At the command line:


# touch /var/log/ipmon.log
# svcadm restart system-log

ProcedureHow to View Oracle Solaris IP Filter Log Files

Before You Begin

You should create a separate log file to record Oracle Solaris IP Filter data. Refer to How to Set Up a Log File for Oracle Solaris IP Filter.

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. View the state, NAT, or normal log files. To view a log file, type the following command, using the appropriate option:


    # ipmon -o [S|N|I] filename
    S

    Displays the state log file.

    N

    Displays the NAT log file.

    I

    Displays the normal IP log file.

    To view all state, NAT, and normal log files, use all the options:


    # ipmon -o SNI filename

    • Provided that you have manually stopped the ipmon daemon first, you can also use the following command to display state, NAT, and Oracle Solaris IP filter log files:


      # ipmon -a filename
      Note –

      Do not use the ipmon -a syntax if the ipmon daemon is still running. Normally, the daemon is automatically started during system boot. Issuing the ipmon -a command also opens another copy of ipmon. In such a case, both copies read the same log information, and only one gets a particular log message.

    For more information about viewing log files, see the ipmon(1M) man page.

Example 26–22 Viewing Oracle Solaris IP Filter Log Files

The following example shows the output from /var/ipmon.log.


# ipmon -o SNI /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

or


# pkill ipmon
# ipmon -aD /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

ProcedureHow to Flush the Packet Log File

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Flush the pack log buffer.


    # ipmon -F
Example 26–23 Flushing the Packet Log File

The following example shows the output when a log file is removed. The system provides a report even when there is nothing stored in the log file, as in this example.


# ipmon -F
0 bytes flushed from log buffer
0 bytes flushed from log buffer
0 bytes flushed from log buffer

ProcedureHow to Save Logged Packets to a File

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Save the logged packets to a file.


    # cat /dev/ipl > filename

    Continue logging packets to the filename file until you interrupt the procedure by typing Control-C to get the command line prompt back.

Example 26–24 Saving Logged Packets to a File

The following example shows the result when logged packets are saved to a file.


# cat /dev/ipl > /tmp/logfile
^C#

# ipmon -f /tmp/logfile
02/09/2004 15:30:28.708294 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 52 -S IN
02/09/2004 15:30:28.708708 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.792611 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 70 -AP IN
02/09/2004 15:30:28.872000 hme0 @0:1 p 129.146.157.149,33923 -> 
 129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872142 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 43 -AP IN
02/09/2004 15:30:28.872808 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872951 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 47 -AP IN
02/09/2004 15:30:28.926792 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN 
.
.
(output truncated)

Creating and Editing Oracle Solaris IP Filter Configuration Files

You must directly edit the configuration files to create and modify rule sets and address pools. Configuration files follow standard UNIX syntax rules:

ProcedureHow to Create a Configuration File for Oracle Solaris IP Filter

The following procedure describes how to set up the following:

  1. Assume a role that includes the IP Filter Management rights profile, or become superuser.

    You can assign the IP Filter Management rights profile to a role that you create. To create the role and assign the role to a user, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

  2. Start the file editor of your choice. Create or edit the configuration file for the feature you want to configure.

    • To create a configuration file for packet filtering rules, edit the ipf.conf file.

      Oracle Solaris IP Filter uses the packet filtering rules that you put in to the ipf.conf file. If you locate the rules file for packet filtering in the /etc/ipf/ipf.conf file, this file is loaded when the system is booted. If you do not want the filtering rules to be loaded at boot time, put the in a file of your choice. You can then activate the rules with the ipf command, as described in How to Activate a Different or Updated Packet Filtering Rule Set.

      See Using Oracle Solaris IP Filter's Packet Filtering Feature for information about creating packet filtering rules.

      Note –

      If the ipf.conf file is empty, there is no filtering. An empty ipf.conf file is the same as having a rule set that reads:


      pass in all
pass out all

    • To create a configuration file for NAT rules, edit the ipnat.conf file.

      Oracle Solaris IP Filter uses the NAT rules that you put in to the ipnat.conf file. If you locate the rules file for NAT in the /etc/ipf/ipnat.conf file, this file is loaded when the system is booted. If you do not want the NAT rules loaded at boot time, put the ipnat.conf file in a location of your choice. You can then activate the NAT rules with the ipnat command.

      See Using Oracle Solaris IP Filter's NAT Feature for information about creating rules for NAT.

    • To create a configuration file for address pools, edit the ippool.conf file.

      Oracle Solaris IP Filter uses the pool of addresses that you put in to the ippool.conf file. If you locate the rules file for the pool of addresses in the /etc/ipf/ippool.conf file, this file is loaded when the system is booted. If you do not want the pool of addresses loaded at boot time, put the ippool.conf file in a location of your choice. You can then activate the pool of addresses with the ippool command.

      See Using Oracle Solaris IP Filter's Address Pools Feature for information about creating address pools.

Oracle Solaris IP Filter Configuration File Examples

The following examples provide an illustration of packet filtering rules used in filtering configurations.

Example 26–25 Oracle Solaris IP Filter Host Configuration

This example shows a configuration on a host machine with an elxl network interface.


# pass and log everything by default
pass in log on elxl0 all
pass out log on elxl0 all

# block, but don't log, incoming packets from other reserved addresses
block in quick on elxl0 from 10.0.0.0/8 to any
block in quick on elxl0 from 172.16.0.0/12 to any

# block and log untrusted internal IPs. 0/32 is notation that replaces 
# address of the machine running Solaris IP Filter.
block in log quick from 192.168.1.15 to <thishost>
block in log quick from 192.168.1.43 to <thishost>

# block and log X11 (port 6000) and remote procedure call 
# and portmapper (port 111) attempts
block in log quick on elxl0 proto tcp from any to elxl0/32 port = 6000 keep state
block in log quick on elxl0 proto tcp/udp from any to elxl0/32 port = 111 keep state

This rule set begins with two unrestricted rules that allow everything to pass into and out of the elxl interface. The second set of rules blocks any incoming packets from the private address spaces 10.0.0.0 and 172.16.0.0 from entering the firewall. The next set of rules blocks specific internal addresses from the host machine. Finally, the last set of rules blocks packets coming in on port 6000 and port 111.

Example 26–26 Oracle Solaris IP Filter Server Configuration

This example shows a configuration for a host machine acting as a web server. This machine has an eri network interface.


# web server with an eri interface
# block and log everything by default; then allow specific services
# group 100 - inbound rules
# group 200 - outbound rules
# (0/32) resolves to our IP address)
*** FTP proxy ***


# block short packets which are packets fragmented too short to be real.
block in log quick all with short


# block and log inbound and outbound by default, group by destination
block in log on eri0 from any to any head 100
block out log on eri0 from any to any head 200


# web rules that get hit most often
pass in quick on eri0 proto tcp from any \
to eri0/32 port = http flags S keep state group 100
pass in quick on eri0 proto tcp from any \
to eri0/32 port = https flags S keep state group 100


# inbound traffic - ssh, auth
pass in quick on eri0 proto tcp from any \
to eri0/32 port = 22 flags S keep state group 100
pass in log quick on eri0 proto tcp from any \
to eri0/32 port = 113 flags S keep state group 100
pass in log quick on eri0 proto tcp from any port = 113 \
to eri0/32 flags S keep state group 100


# outbound traffic - DNS, auth, NTP, ssh, WWW, smtp
pass out quick on eri0 proto tcp/udp from eri0/32 \
to any port = domain flags S keep state group 200
pass in quick on eri0 proto udp from any port = domain to eri0/32 group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = 113 flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 port = 113 \
to any flags S keep state group 200

pass out quick on eri0 proto udp from eri0/32 to any port = ntp group 200
pass in quick on eri0 proto udp from any port = ntp to eri0/32 port = ntp group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = ssh flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = http flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 \
to any port = https flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = smtp flags S keep state group 200


# pass icmp packets in and out
pass in quick on eri0 proto icmp from any to eri0/32  keep state group 100
pass out quick on eri0 proto icmp from eri0/32 to any keep state group 200


# block and ignore NETBIOS packets
block in quick on eri0 proto tcp from any \
to any port = 135 flags S keep state group 100

block in quick on eri0 proto tcp from any port = 137 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any to any port = 137 group 100
block in quick on eri0 proto udp from any port = 137 to any group 100

block in quick on eri0 proto tcp from any port = 138 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any port = 138 to any group 100

block in quick on eri0 proto tcp from any port = 139 to any flags S keep state
group 100
block in quick on eri0 proto udp from any port = 139 to any group 100
Example 26–27 Oracle Solaris IP Filter Router Configuration

This example shows a configuration for a router that has an internal interface, ce0, and an external interface, ce1.


# internal interface is ce0 at 192.168.1.1
# external interface is ce1 IP obtained via DHCP
# block all packets and allow specific services
*** NAT ***
*** POOLS ***


# Short packets which are fragmented too short to be real.
block in log quick all with short


# By default, block and log everything.
block in log on ce0 all
block in log on ce1 all
block out log on ce0 all
block out log on ce1 all


# Packets going in/out of network interfaces that aren't on the loopback
# interface should not exist.
block in log quick on ce0 from 127.0.0.0/8 to any
block in log quick on ce0 from any to 127.0.0.0/8
block in log quick on ce1 from 127.0.0.0/8 to any
block in log quick on ce1 from any to 127.0.0.0/8


# Deny reserved addresses.
block in quick on ce1 from 10.0.0.0/8 to any
block in quick on ce1 from 172.16.0.0/12 to any
block in log quick on ce1 from 192.168.1.0/24 to any
block in quick on ce1 from 192.168.0.0/16 to any


# Allow internal traffic
pass in quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24
pass out quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24


# Allow outgoing DNS requests from our servers on .1, .2, and .3
pass out quick on ce1 proto tcp/udp from ce1/32 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.2 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.3 to any port = domain keep state


# Allow NTP from any internal hosts to any external NTP server.
pass in quick on ce0 proto udp from 192.168.1.0/24 to any port = 123 keep state
pass out quick on ce1 proto udp from any to any port = 123 keep state


# Allow incoming mail
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = smtp keep state


# Allow outgoing connections: SSH, WWW, NNTP, mail, whois
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 22 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 22 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 443 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 443 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = nntp keep state
block in quick on ce1 proto tcp from any to any port = nntp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = nntp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = smtp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = whois keep state
pass out quick on ce1 proto tcp from any to any port = whois keep state


# Allow ssh from offsite
pass in quick on ce1 proto tcp from any to ce1/32 port = 22 keep state


# Allow ping out
pass in quick on ce0 proto icmp all keep state
pass out quick on ce1 proto icmp all keep state


# allow auth out
pass out quick on ce1 proto tcp from ce1/32 to any port = 113 keep state
pass out quick on ce1 proto tcp from ce1/32 port = 113 to any keep state


# return rst for incoming auth
block return-rst in quick on ce1 proto tcp from any to any port = 113 flags S/SA


# log and return reset for any TCP packets with S/SA
block return-rst in log on ce1 proto tcp from any to any flags S/SA


# return ICMP error packets for invalid UDP packets
block return-icmp(net-unr) in proto udp all