SunScreen EFS 3.0 Function Details

The following SunScreen EFS 3.0 functions are described in more detail:

• Dynamic packet filtering

• Network address translation (NAT)

• High availability

• Time-based rules

• User authentication

• Event logging with proxies

• Encryption and decryption

• Address management

• Services and service groups

• Policy rules

• Tunneling and VPNs

Dynamic Packet Filtering

Dynamic packet filtering enables a Screen, which sits between the client and server, to examine each data packet as it arrives. Based on information in the packet, state retained from previous events, and a set of security policy rules, the Screen either passes the data packet, or blocks and drops it.

SunScreen EFS 3.0 uses a set of ordered rules to filter packets. When you configure SunScreen EFS 3.0, you translate the security policies for your site into a series of policy rules that specify which services are to be allowed, what to do with packets for services that are disallowed, and what to do when packets are dropped. You then place these policy rules in sequence to specify which rules override others.

When the Screen receives a packet, it tests the packet against the two certificates, the algorithms, and the rules in the order in which they are numbered. The Screen does not test each packet against each rule; it assumes that the first rule to match the service, source address, and destination address of the packet addresses is the rule that governs the disposition of the packet. Additionally, if the applicable rule so specifies, the Screen can record a log message or generate an SNMP alert.

If the packet does not match any rule, the Screen uses its default action for the interface on which the packet arrived to determine disposition of the packet. Typically, this action logs the packet and drops it, though other options are available.

Network Address Translation (NAT)

SunScreen EFS 3.0 NAT gives you fine-grain control by adding ordered NAT translations, allowing table entries to intersect, and allowing you to specify when to have NAT translate the source or destination addresses.

NAT enables a Screen to map an internal network address to a different network address. As it passes packets between an internal host and a public network, the addresses in the packet are replaced with new addresses transparently, checksums and sequence numbers are corrected in both the IP header and the TCP or UDP header, and the state of the address map is monitored. You specify when a packet using ordered NAT translations is applied based on source and destination addresses.

Be sure to configure your NAT rules to not perform address translation while an internal host is attempting to communicate directly with the Screen.

Additionally, services such as FTP also carry IP address information. These packets must also be changed, ensuring that the checksums and sequence numbers are correct. All of this is done inside the Screen's kernel to ensure high-speed processing and transparency to the end user and applications. NAT is stateful, which increases the efficiency of lookups in the address translation table by using address hashings and checksum adjustments that use differential checksum calculations.

NAT is typically used in the following situations when:

• Renumbering all the hosts in your network is not feasible.

• The current private network uses a set of private, unregistered IP addresses due to a lack of available public addresses, or to simplify renumbering hosts should you change ISPs.

• You have a very large network to connect, but your Internet Service Provider (ISP) allotted you a limited range of IP addresses.

• You want to hide the addresses on the current private network from the outside world.

Using NAT to hide addresses differs from tunneling in that NAT does not rely on the use of encryption and decryption and consequently does not require an encryption-decryption device at each end of the connection over the public network.

NAT lets you use private or unregistered Internet addresses to number your internal networks and hosts and still maintain full connectivity to the Internet. The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

• 10.0.0.0-10.255.255.255 (Class A address range, which supports about 16 million addresses)

• 172.16.0.0-172.31.255.255 (Class B address range, which supports about 65,000 address)

• 192.168.0.0-192.168.255.255 (Class C address range, which supports 254 addresses)

With this approach, you can use a registered Class C address space, which offers about 254 externally routable addresses, to provide connectivity for an unregistered Class B network, which supports approximately 65,000 hosts or 255 networks of 254 hosts (internally).

Static NAT

Registered addresses are necessary for advertised kinds of resources, such as publicly accessible servers on your network, because these machines must be at well-known, fixed addresses. Static NAT is frequently used to provide public access to HTTP or FTP servers that use private addresses. These servers must use static NAT reverse rules so that other hosts can use the same registered addresses to reach them, so the reverse rules must be generated by you.

Static NAT maps a specific unregistered address to a specific registered address. Static translations can also map a range of unregistered addresses to a range of registered addresses, which requires the number of addresses in each range to match.

Dynamic NAT

Dynamic NAT maps a large set of unregistered IP addresses to a smaller set of registered addresses. Dynamic NAT lets you connect a very large number of hosts to the public Internet using a limited number of registered addresses.

Unlike static NAT, which sets up a one-to-one mapping between internal private addresses and external public addresses, dynamic NAT creates a many-to-one mapping where several internal addresses use the same public address. Dynamic NAT avoids IP address conflicts by maintaining a state table that records five values (source address, source port, destination address, destination port, and protocol) for each TCP or UDP connection. When the Screen uses a public address that is already in use, it uses a different source port number, thereby making a distinction between the two connections. A Screen can multiplex many thousands of translations over a single registered address by ensuring the source ports for the connections differ.

Dynamic NAT is unidirectional, meaning that communication can be initiated only internally from the unregistered private network. Dynamic NAT only works when a user originates a connection from inside the firewall; packets from outside that are not in the address lookup table of an established connection cannot identify a host on the private network and are discarded.

NAT Examples

The following NAT examples show how to set up NAT mappings when using only one registered IP address, and shows two scenarios that illustrate how a demilitarized zone could use registered addresses or unregistered addresses with NAT.

Example One:

When you only have one registered IP address ("A") and you want to have all inbound traffic to "A" go to your Screen and have all other hosts use that address ("A") for unidirectional, outbound traffic, then set up the following NAT mappings:

where "Internet" is all addresses on inbound interface "qe0" and "A"; and "Inside" is all internal hosts on all other interfaces. With only these NAT rules, all hosts in the "Inside" communicate with their private, unregistered, addresses when communicating with the Screen or among themselves.

Write your filtering rules in the context of the internal addresses.

Valid mapping combinations are:

• "Source" and "Translated Source" are the same, and "Destination" and "Translated Destination" are the same (no translation will occur).

• "Source" and "Translated Source" are the same, and "Destination" and "Translated Destination" are different.

• "Source" and "Translated Source" are different, and "Destination" and "Translated Destination" are the same.

• You cannot translate both the source and destination addresses in any single packet with either a single mapping or in a combination of mappings.

Example Two:

Registered addresses are necessary for advertised kinds of resources, such as publicly accessible servers on your network, consequently these machines must be at well-known, fixed addresses. Because a host must have a registered address before it can communicate over public networks, either machines that host public resources must have stable registered addresses, or their internal (unregistered) addresses must translate to stable registered addresses. The following scenarios illustrate how a demilitarized zone (DMZ), an internal network with limited public access, could use registered addresses or unregistered addresses with network address translation.

Scenario 1: DMZ Uses Registered Addresses

In FIGURE 2-5, the Screen, in routing-mode, uses Q1 as its own IP address on the external network interface. It has a DMZ network with registered addresses R1 through R8 on a second interface. The Screen (Q1) and the servers in the DMZ (the FTP server (R2) and the WWW server (R3)) have routable registered addresses on the public network that allow them to communicate with any other machine with a registered address. The Screen uses the remaining registered addresses (R4 through R8) for NAT.

Figure 2-5 Scenario 1: Static and Dynamic NAT

The Screen uses dynamic NAT to map the addresses in its unregistered address range (U2-Un) to map the remaining addresses in its registered address range (R4-R8). When an internal host with an unregistered address tries to connect to an external host with a registered address, the Screen assigns the internal host a registered address to use for the duration of the network communication session.

Scenario 2: DMZ Uses NAT Addresses

FIGURE 2-6 illustrates an organization that has a network consisting of a large number of unregistered addresses (Un) and a set of eight registered addresses (R1-R8). Hosts on the inside network must be able to communicate through the Screen with external hosts.

Figure 2-6 Scenario 2: Static and Dynamic NAT

In FIGURE 2-6, the Screen is connected to the public network R1-R8. R1 is its IP address on the public network interface. It uses static NAT to map the unregistered DMZ addresses of the FTP server (U2) and the WWW server (U3) to the registered (public) addresses R2 and R3. The private addresses U4 through Un will be mapped dynamically to the registered addresses R4 through R8. Because the IP addresses of the servers and the internal network are translated to routable registered addresses, they can communicate with any other registered address.

In routing-mode (not needed in stealth-mode), the Screen must respond to ARP requests the public addresses (R2 through R8) because it will be translating public addresses to private addresses. You must add an arp entry (using the command arp -s IP_address ether_address pub) for them. You must either add this entry each time that you reboot the Screen or add it to the /etc/inetd.conf file. If you are remotely administering the Screen in routing mode, you either must go to the Screen to add this entry, or you must have a rule in your policy that allows you to log in remotely (rlogin) to your Screen.

The Screen uses dynamic NAT to map the addresses in its unregistered address range (U4-Un) to the remaining addresses in its registered address range (R4-R8). When an internal host with an unregistered address tries to connect to an external host with a registered address, the Screen assigns the internal host a registered address to use for the duration of the network communication session.

This scenario has the advantage that, if you change ISPs, you do not have to readdress all the hosts on your internal registered network.

Applying NAT

NAT mappings for your site are automatically applied to all packets. When packets addressed to an internal host are received from an external host, the Screen translates network address information in the packets before they are processed by the stateful packet-filtering engine. Similarly, packets travelling from an internal host to an external host are filtered before NAT takes place. This approach lets you use your internal addresses when you define filtering rules, simplifying policy management.

NAT and Mapping Collisions

Mapping collisions can cause service to be denied to a network user. Mapping collisions occur when network software cannot complete the address mapping process because two or more packets are not uniquely identified. Each packet must have a destination IP address, a destination port, source IP address, a source port, and protocol if it is to be delivered. These elements are processed as a 5-tuple of information of the form: (dest IP addr, dest port, srcaddr, src port, proto), which is part of the packet header.

A 5-tuple is unique as long as at least one of the five pieces of data that it contains differs from the others with which it is being compared. Since each piece of data has a large number of possible values, the number of possible permutations for the 5-tuple is enormous. For a mapping collision to occur, multiple internal machines using the same registered IP address must try to access the same registered address Xn at the same destination port number, and from the same source port number, all at the same time-an unlikely scenario.

Suppose a user at the unregistered address U5, shown in FIGURE 2-5, attempts to go to a Web page at the registered destination address 192.4.15.37 at destination port 80 from source port 34080 through the registered address R5. Another user at U6 can do the same to the same address and destination port through source port 34070, or go to a different Web page through source port 34080.

The following table shows a mapping of unregistered addresses, Un, to registered addresses, Rn.

If a user at unregistered address U7 attempts to go to a web page at the registered destination IP address 192.4.15.44 at destination port 80 from source port 34080 using registered address R4, a mapping collision will occur. The user at U7 would have to use another source port to have a unique 5-tuple and avoid a mapping collision, which would happen automatically during a subsequent connection attempt.

Situations such as power failures typically result in mapping collisions. When power is restored, all hosts on a network come up at the same time and try to reestablish network connections. Each host's operating system resets its source port counter to a low number. It may take time for the counters on each machine to cycle up to higher and more randomized port numbers (which are more likely to produce unique 5-tuples). In the interim, mapping collisions may cause network service to be denied temporarily. Internal hosts must continue trying to establish network connections until the NAT rules resolve the mapping collisions.

Ports 0 though 1024 are reserved for well-known port assignments and are controlled by the IANA. To avoid conflicts, the Solaris operating environment uses ports that range approximately from 32768 through 65535

High Availability (HA)

HA lets you deploy groups of Screens together in situations where the connection between a protected inside network and a nonsecure outside network is critical. At any time, one member of the HA cluster is the active Screen, which performs packet filtering, network address translation, logging, and encryption or decryption of packets travelling between the inside and outside networks. The other members of the HA cluster, the passive Screens, receive the same packets, perform the same calculations as the active Screen, and mirror the state of the active Screen, but they do not forward traffic.

HA Policy

When you set up an HA cluster, you designate one Screen as its primary HA Screen that is configured with the policy's configuration objects, including named Screen objects, like Address or Service with attributes that include these settings, and policy rules that the HA cluster will use. When you activate the security policy, the SunScreen EFS 3.0 and SunScreen SKIP policies are copied from the primary HA Screen to the secondary Screens in the HA cluster.

Solaris policy settings, such as network interfaces and routing configuration, are not copied from the primary Screen and must be identical on all the Screens in the HA cluster.

Because the HA cluster transmits secret keys and policies in the clear over the dedicated HA network, you must keep the HA network physically secure.

The interfaces for network connections must be the same for each HA cluster member. Similarly, you must assign all HA Screens the same IP addresses on their non-dedicated interfaces as well. The following figure shows a network protected by two Screens in an HA cluster. Each Screen in the HA cluster connects to the external and internal networks through Ethernet hubs, which pass the same signals to all HA cluster members at the same time. Each HA Screen therefore sees the same traffic, ensuring that passive Screens can duplicate the state of the packet filter engine should the active Screen fail.

Figure 2-7 Network With HA Cluster of Screens

HA Network Connections and Failovers

When the active HA cluster Screen is an x86 machine running Solaris 7, failover does not work properly. The ETHER_ADDRESS for the primary does not set correctly.

Once the HA cluster is running, the active and passive Screens poll each other every few seconds to verify connectivity and status. If the active Screen fails or becomes unavailable, the passive Screen that has been running the longest takes over as the active Screen within 15 seconds. During this time (before the passive Screen takes over), no traffic will go through the HA policy.

HA is designed to maintain the great majority of network connections. In the case of a reboot (an orderly shutdown), the active Screen being rebooted notifies the passive Screens, and the appropriate passive Screen takes over as the active Screen without loss of connections. Because the passive Screens do not forward, reject, or log packets, the load on passive Screens is less than the load on the active Screen. Consequently, load-induced faults that affect the active Screen are unlikely to affect the passive Screens.

If a failover occurs, these connections may be disrupted:

• Continued connections, for protocols that keep state (memory), such as TCP connections.

• Stateful connections, such as FTP, NFS, NIS, and RPC.

These connections may be lost if one of the following conditions occurs:

• The Screen taking over filtering does not have all the same state information when the failover condition occurs.

• Although rare, a connection through the HA cluster uses dynamic NAT and two or more connections have identical destination addresses, destination ports, or source ports.

HA automatically disconnects if it is only running on one machine, allowing it to act like a standard SunScreen EFS 3.0 Screen.

You choose to configure SunScreen EFS 3.0 as an HA cluster during installation. Alternatively, you can configure HA settings through the command line, as described in Appendix B, "Command Line Reference."

HA Alerts

Note the following HA limitations:

• HA is currently only supported in routing mode.

• HA does not work on x86 machines running Solaris 7.

• Screens in an HA cluster do not exchange state information, they independently accumulate state by processing the same packets. For optimal performance, whenever possible, it is recommended that an HA cluster comprise systems of equal size (same CPU speed, and memory size). A slower Screen in passive mode can fall behind in processing and eventually fail to have the same state as the active Screen.

• To reinstate a repaired Screen back into an HA cluster, install it as a secondary Screen and add it to the cluster.

It is not necessary to switch back to the original Screen except when its abilities or speeds are better. If they are, you can force the faster machine to take over as the active Screen, or wait until both machines have the same state because eventually the out-of-sync connections will timeout and become synchronized, then force the failover.

• Secrets are sent in the clear on the dedicated HA network. This is done intentionally to facilitate administrative communication within the HA cluster. Reserve the HA interface as a separate network from other traffic to avoid the possibility of the Screen's private certificates being discovered.

• Each Screen in an HA cluster must have a unique nodename and a unique IP address on the dedicated HA network. All other aspects of the Solaris system configurations must be identical on all Screens in the HA cluster. This includes the configuration of all network interfaces (other than the HA interface).

• HA does not work well with proxies because proxy state tables are not present on all HA machines.

• The HA Screens must be connected to each other through a shared network (such as a 10BaseT or 100BaseT hub) and not through a switched network (such as an Ethernet switch because it would send each packet to only one HA Screen, rather than to all of them).

• HA cannot be used on networks that use media other than Ethernet, such as FDDI, Token-Ring, or ATM.

• Because passive HA hosts do not generate traffic (other than automatic administrative traffic, such as HA administration and HA heartbeat), you cannot telnet into passive HA Screens. You can telnet into an active HA Screen only.

• In general, the HA cluster decides internally which member will be the active Screen. If you need to remotely administer the HA cluster, you may first need to connect to the secondary Screen and direct it to become passive so that you can communicate with the primary Screen.

Time-Based Rules

Time-based rules are time objects that are specified using a 24-hour clock in 5-minute increments. They allow you to set a policy's time-of-day, day-of-week, and so forth, rules. For instance, you may want to allow telnet but only during regular business hours, or after hours, or outside certain hours.

The policy rule default setting is ANY time, which applies the rule at all times like in prior SunScreen firewall releases. You can set a few time-based policy rules that reference the same set of hours, or you can specify specific hours covered in a specific day such as Monday to Friday, 9 a.m. to 5 p.m., local time.

Time is always interpreted as the Screen's time zone, which requires that you either have Screen-specific Time definitions to coordinate traffic between the Screens in different time zones, or have distinctly-named Time objects and Screen-specific rules.

Although you can define many Time objects, only 31 distinct Time objects can be in actual use on any given Screen.

For example, Los Angles (LA) and New York (NY) have a three hour difference. If you only want the two sites to communicate when they are both within "regular" hours (that is, 8am to 5pm), then NY is available to communicate to LA between 11am and 5pm, and LA is available to communicate to NY between 8am and 2pm.

A down-side to this is that during hours that do not overlap, one of the two Screens allows traffic through while the other will not. So, early in the morning the NY Screen allows traffic through, but it is blocked by the LA Screen. Similarly, in the afternoon, the LA Screen is blocked by the NY Screen.

Case 1: Screen-Specific Time Objects

Set the rules by typing:

telnet LA NY TIME regular ALLOW
telnet NY LA TIME regular ALLOW

Case 2: Distinctly-Named Time Objects

Set the rules by typing:

SCREEN LA telnet LA NY TIME la-business ALLOW
SCREEN LA telnet NY LA TIME la-business ALLOW
SCREEN NY telnet LA NY TIME la-business ALLOW
SCREEN NY telnet NY LA TIME la-business ALLOW

User Authentication

SunScreen EFS 3.0 allows you to configure user entities to authenticate individual administrators and to allow access through the firewall when using proxied services.

Authentication allows you to verify the identity of both internal and external users based on user name and a simple text password, or on a user name and SecurID\256 token passcode, or both.

Proxies provide a means to validate, regulate, and extend the abilities of certain services beyond those afforded by kernel-based stateful packet filtering. (See Chapter 5, "Proxies," for more information regarding user authentication.)

SunScreen EFS 3.0 provides two distinct levels of user identification: Authorized User, through the authuser database, and Proxy User, through the proxyuser database.

Authorized Users

Authorized User is a named common object that describes an individual administrative user who is distinct from all others. The attributes provide a repository for demographic and authentication data about that individual.

Access to and use of the administrative GUI functions require that you establish the Authorized User identity before administration is allowed. Both the administration GUI Login screen and the login sub-command of the ssadm command line facility reference an Authorized User object.

Authorized User authenticity establishes only the identity of an individual administrator, not the various roles they may play while using SunScreen EFS 3.0. Role establishment is afforded in one of two ways: (1) reference within the User field in the administrative access rules of a policy, (2) reference from a packet filtering rule that utilizes user authentication (proxies).

Proxy Users

Proxy User is a named common object distinct from the Authorized User. Proxy Users are either SIMPLE or GROUP objects. SIMPLE objects are used to provide for and establish an association between an individual administrator and the role they play in usage of the facilities controlled by SunScreen EFS 3.0. GROUP objects are used to allow creation of groups of SIMPLE Proxy Users that share common access to facilities. Thus, GROUPs streamline the task of allowing or removing access to established facilities.

Some special Proxy User objects also provide the means to map external collections of users into the SunScreen EFS 3.0 access control facilities. SunScreen EFS 3.0 provides external access to SecurID and RADIUS users. (Access to other external user databases is afforded using RADIUS as an intermediary agent. For example, access to LDAP user databases stored through Sun Directory Services (SDS) are accessible through RADIUS.)

The following diagram summarizes the relationship between Rules, Authorized Users, Proxy Users, and external user databases:

Authorized Users and Proxy Users names are distinct, and you can have objects with identical names in each. Choose a naming strategy for each set that best reflects the naming systems already employed. For example, you can choose to name Authorized Users by employee identities, like distinguished names or employee numbers, and Proxy Users by names that reflect their normal user login names deployed on server systems (for example: Unix login name).

Names cannot contain any of the following characters: "!", "#", "$", "%", "^", "&", "*", "{", "}", "[", "]", "<", ">", """, "', "?", "`", "/", "@", or NUL characters.

Space, tab, and other whitespace characters are allowed in names, but in doing so you should be prepared to supply quotation marks in some situations in order to protect such whitespace within names.

Names of Authorized Users, Proxy Users, and other user naming items are often deliberately chosen to be different for purposes of clarity.

Event Logging With Proxies

Event logging (failure and success, including subsystem authentication) through the log browser supports filtering and ordering capabilities to define and store named filtering and sorting macros. The size of the log is configurable. The log collection facility allows the proxies to add information to the current log. The types of logged events are extensible to anticipate the evolving use of this facility. Filtering and ordering automates uploading, storage, and post-processing of logs. You can create post-processing of your choice of uploaded logs (for instance, analysis and compression).

Encryption and Decryption

Encryption is the process by which a readable message is converted to an unreadable form to prevent unauthorized parties from reading it. Decryption is the process of converting an encrypted message back to its original (readable) format. The original message is called the plaintext message. The encrypted message is called the ciphertext message.

Digital encryption algorithms work by manipulating the content of a plaintext message mathematically, using an encryption algorithm and a digital key to produce a ciphertext version of the message. The sender and recipient can communicate securely if the sender and recipient are the only ones who know the key.

Encryption is important to SunScreen EFS 3.0 because it provides a mechanism for protecting the privacy of communications and authenticating the identities of the sender and receiver. Without encryption, you would have to define packet screen rules broadly: "all the machines on the Internet" and "all the machines on the inside." Encryption technology lets you authenticate machines and users. As a result, you can define rules that control access by specific cryptographic identities rather than by general IP addresses.

SunScreen EFS 3.0 uses the SunScreen Simple Key-Management for Internet Protocols (SKIP) as the basis for its encryption technology. SKIP provides secure, encrypted communication between a remote Administration Station and the Screen and between a Screen and a remote SKIP host.

For detailed information on how SKIP encryption works, refer to the SunScreen SKIP 1.5 User's Guide.

Address Management

SunScreen EFS 3.0 identifies network elements--networks, subnetworks, and individual hosts--by mapping a named address object to one or more IP addresses. SunScreen EFS 3.0 uses address objects to define the network elements that make up the policy. These address objects are then used in defining SunScreen EFS 3.0's network interfaces and as the source and destination addresses for rules and for NAT. An address object can represent a single computer or a whole network. You can gather address objects representing individual and network addresses together to form address groups. SunScreen EFS 3.0 lets you define address objects that specifically include or exclude other address objects (single IP hosts, ranges of contiguous IP addresses, or groups of discontiguous IP addresses).

Individual IP Addresses

SunScreen EFS 3.0 identifies an individual host by linking its unique IP address to an address object, which can use the name or IP address of the host or some other identifier. FIGURE 2-8 shows an example of a host identified by its IP address (172.16.1.1).

Figure 2-8 Single Host Address

Address Ranges

An address range is a set of numerically contiguous IP addresses. Networks and subnetworks are typically identified by an IP address range name. You use the beginning and ending addresses to identify an IP address range,

You can set up an address object to represent an address range in SunScreen EFS 3.0. FIGURE 2-9 shows examples of ranges of addresses for the Corporate and Sales networks. For example, the Corporate address object is defined as a range of addresses from 172.16.3.2 to 172.16.3.255. You could then establish access or encryption rules for hosts on the Corporate network by indicating the rule applies to the Corporate address object.

Figure 2-9 Examples of IP Address Ranges

Address Groups

An address group is a collection of host addresses, address ranges, and other address groups. After you set up an address group, you can use it to identify multiple hosts as a single element. You can define groups in terms of the addresses they include ("Address group A consists of the IP address 1.2.3.4 and the members of address group B"), the addresses they exclude ("Address group C consists of all the hosts on the 192.4.5.0 network except 192.4.5.5 and 192.4.5.9"), or both. Address groups cannot be self-referential; that is, you cannot include address group X as a member of address group Y and then define address group Y as a member of address group X.

There are two addresses you cannot modify: localhost, which is the IP address(es) of the actual SunScreen, and "*", which represents all IP addresses.

The value is determined by first, all Addresses are included, which means that all the IP addresses contained in any of them are added to the Address Group. Next, all IP addresses of all the Addresses that are excluded are removed from the Address group. You cannot control the order in which the IP addresses are added or removed, as all includes are done before all excludes.

Designing an Addressing Scheme

You can take several steps when creating address objects to simplify maintenance of your security policies. When you are planning your addressing scheme, choose interface names that describe which addresses are on that interface or that reflect the names of the interfaces. Make naming conventions meaningful and consistent so that maintenance and daily administration are uneventful.

A network interface is a network connection coming into a Screen through which one or more IP addresses are accessible. These IP addresses need to be identified to SunScreen EFS 3.0 so that IP spoofing can be detected and prevented.

The easiest way to define address objects for network interfaces is to define an address group for each network interface. You can choose names that identify which addresses are on that network interface (such as, Corporate, Sales, ftp-www, and Internet) or names that identify the interfaces by type (such as le0 or qe0).

In most cases, one interface usually has the majority of addresses on it. For example, the Internet network interface (qe0) in the network illustrated in the figure, has the most addresses, since it is the interface for all addresses except those in the Corp, ftp-www, and Sales networks.

Figure 2-10 SunScreen EFS 3.0 as Internet Firewall

Rather than enumerating all the addresses for the Internet, you can define the address group for the Internet address object to includes all network addresses ("*") and then exclude those that you do not want to be part of that address. In the example shown in the figure, you would define the Internet address object as an address group that includes all addresses except Corp, Sales, and ftp-www. You would then define which hosts, networks, or address groups are members of the Corp, Sales, and ftp-www addresses to exclude them from the Internet address group.

Services and Service Groups

SunScreen EFS 3.0 is shipped with a number of predefined network services, such as ftp, telnet, dns, and rsh. You can modify these services or define new services as needed.

A well-defined service must not include two entries for the same port with different attributes, such as two different filters for the same port but with different state engines, or the same state engine but with different parameters set.

Standard Services

Part of setting up your network security policy is to define what network services will be available to hosts on your internal network and to hosts on the external network. Generally, most sites need to determine or set up rules that govern the basic services.

Besides the basic services, every TCP/IP implementation provides services such as echo, discard, daytime, chargen, and time. For services such as ftp, you may want to allow anyone in the internal corporate network to send outbound traffic, but only allow inbound traffic in this protocol to go to the FTP server. This requires two rules: one for the outbound traffic and one for the inbound traffic going to the public server.

Each service uses a state engine, a sort of protocol checker. For example, the FTP state engine checks port numbers when the ftp service is being used. For more information on state engines, see Appendix B, "Services and State Engines."

Table C-1 in Appendix C, "Services and State Engines," lists the single services in SunScreen EFS 3.0, along with the state engine and discriminator (port, RPC program number, or type). Parameters (state engine modifiers, such as timeouts) and BROADCAST are indicated where applicable.

Modifying or Creating New Services

You can modify or define existing services or define new services as needed. Each service must use a predefined state engine. When you define a new service, you must specify a state engine for the new service to use and identify the various discriminators and parameters appropriate for that state engine.

Before you can define a new network service, you need to identify how the new service will work:

• What protocol does the new service use?

• What ports does the protocol use?

• If your service is an RPC protocol, what program numbers does it use?

• If your service is a UDP protocol, how many responses can be sent back for each request?

For example, if you have an FTP implementation that uses port 45 for its control port and port 44 for data, you could define a new FTP service called ftp-45. Refer to Appendix B, "Services and State Engines," for more information on state engines, their discriminators, and their parameters.

You can specify state engines as filters for both the forward and the reverse direction. The forward filters apply when traffic originates from the From Address and goes to the To Address in a rule. The reverse filters apply to traffic originating from a machine in the To Address going to the From Address of a rule.

Normally, rules for stateful services do not have reverse filtering rules. For instance, an FTP connection always gets established in the forward direction, and the returning traffic is handled by a state-table entry created when the connection is initiated. Reverse filtering rules are mostly valuable when you want to allow nonstateful traffic to return. An example is the nlm rule, which uses the nonstateful ICMP filter engine. It allows network lock manager (nlm) requests (ICMP type 8) in the forward direction and nlm replies (ICMP type 0) in the reverse direction.

State engines' discriminators can optionally be tagged with a BROADCAST attribute. When BROADCAST is specified for a service, the rules where the service is used allow communication to broadcast and multicast addresses. If you also want the service to work for non-broadcast addresses, you must include a filter line both with and without BROADCAST selected.

Service Groups

You can group network services together to apply a single rule to multiple network services. This group is called a Service Group. Table C-1 in Appendix C, "Services and State Engines," shows the predefined Service Groups in SunScreen EFS 3.0 and the services each includes. Not every service is included in a service group.

You can create additional service groups using any combination of the individual network services. A useful group to define might be an "internet services" group, consisting of public services, such as FTP, email, and WWW.

Policy Rules

Policy rules are based on sets of ordered policy rules. You set up these rules to reflect the security policy for your site. These rules specify the action to be taken for services between two addresses that are on different interfaces of the Screen.

When you install the SunScreen EFS 3.0 software, you start with a policy object called Initial that establishes access rules for basic TCP/IP services. You then define policy rules to allow clear or encrypted communication between hosts that meet your criteria.

Each rule must specify all three selection criteria: source address, destination address, and type of service. Each rule can also specify what action to take if a packet meets those criteria. For example, different rules will specify whether the Screen should forward or drop the packet; encrypt or decrypt the packet; record the packet in the Screen logs; and issue ICMP messages or SNMP traps concerning the packet. The default rule is to drop any packet that does not have a specific Encryption or Allow action.

The sequence in which rules are ordered is critically important. When the Screen processes packets, it compares the packet information to each rule in the order it occurs in the Screen's active policy. When a packet meets the criteria of a rule, the Screen applies the actions specified for that rule and disregards the following rules.

You can use the administration GUI or the command line (see Appendix B) to set up the table of ordered rules for a policy, which allows you to edit rule components, such as source and destination addresses, directly. You can change the order of the rules by dragging and dropping them through the configuration editor.

Rule Syntax

The basic syntax for a rule is:

Service Source_address Destination_address optional_Time optional_Encryption "action" optional_Proxy

where:

• Service - An individual network service or a group of services provided to users. Sample services are email, remote login, and ftp.

• Addresses - Named addresses to define the network elements that make up the configuration. A named address can represent an individual address, as a range of addresses, or as a group of addresses. Named addresses are also used to define the network interfaces.

  • Source_Address - An address object from the client side over which these services are provided to users.

  • Destination_Address - An address object from the server side over which these services are provided to users.

• Encryption - (Optional) The version of SKIP to used for encryption, in one of two forms: SKIP_VERSION_1 source_cert dest_cert key_algorithm data_algorithm, or SKIP_VERSION_2 source_cert dest_cert key_algorithm traffic_algorithm mac_algorithm.

  ---

  Note -

  Encryption is only supported if ALLOW is selected. It is not supported if any Proxy or VPN is selected.

  ---

Encryption works as follows:

• If the first certificate is local (the secret key is loaded into SKIP on the Screen), then the rule is considered an encryption rule. The packet will be encrypted on its way out of the Screen.

• If the second certificate is local, then the rule is considered a decryption rule, and the packet will be verified as having been decrypted accordingly (correct certificates and algorithms) before it is allowed to pass.

• If neither certificate or if both certificates are local, then the rule is ignored by the compilation process.

• Action - What the Screen should do with packets. The choices are ALLOW and DENY. The syntax for specifying an action is in the form: ALLOW LOG_information SNMP_information; for example, ALLOW LOG_SUMMARY SNMP_NONE or DENY LOG_INFORMATION SNMP_INFORMATION ICMP_INFORMATION.

• Proxy - (Optional) The name of the proxy to be enabled and any flags for the proxy. Proxy flags are only permitted in a Rule when the service is a PROXY_* service, where * is the type of proxy and the flags must be of the type for that proxy. The syntax for specifying a proxy is in the form: PROXY_proxy_name proxy_name flags; for example, PROXY_HTTP HTTP flags, PROXY_FTP FTP flags, or PROXY_SNMP SNMP flags. The telnet proxy does not take flags.

• User - (Optional) A name in the proxy database of users. The syntax for specifying a user is USER user_name, where user_name is a name in the proxy database.

  ---

  Note -

  The optional User field is only supported if the rule is Proxy-ftp or Proxy-telnet. Otherwise, the Screen does not support user-based rule criteria.

  ---

• Time - (Optional) A component that allows time-of-day-based Policy Rules. The syntax for specifying time is in the form: time_object_name.

• VPN - (Optional) A component that allows you to no longer specify all the SKIP information, but have the Screen do it for them. The syntax for specifying VPN is in the form: vpn_name.

  ---

  Note -

  VPN is not support if any SKIP information is specified, if DENY is selected, or if any Proxy is specified.

  ---

Example of a Rule Configuration

The XYZ Company wants to set up a series of rules to implement the following security policies:

1. Allow telnet traffic from A (an address object representing an individual host) to B (an address object representing any host on a specified network).

2. Deny and log mail traffic between A and B.

3. Send a NET_UNREACHABLE ICMP rejection messages for rejected telnet traffic.

4. Discard all other packets.

TABLE 2-2 illustrates the rules the XYZ Company would set up to implement this security policy. Note that the default action would be specified as DENY for each interface to implement policy 4.

Tunneling and VPNs

Organizations typically have offices in more than one location. SunScreen EFS 3.0 provides a tunneling mechanism to let the different offices use public networks as a secure private network without needing dedicated lines and with no changes to user applications.

When editing multiple rules with ENCRYPT as the ACTION value, the tunnel address settings of the first rule you edit is copied into the next rule you edit. Use the command-line interface to modify the tunnel address settings of these rules.

When a tunnel, or virtual private network, is set up between two locations, all data packets traveling from one location to the other are encrypted and encapsulated inside other packets before they are sent over the public internetwork. Encrypting the packets guarantees that their contents will remain private; anyone capturing packets to snoop on network traffic between the two locations will be unable to read them. When the packets arrive at the remote location, they are decapsulated, decrypted, and forwarded to their intended destination.

In addition to protecting the privacy of network traffic, tunneling also lets a site conceal the details of its network topology from intruders or eavesdroppers. Because the original packets are encrypted, the source and destination addresses in their IP headers cannot be read. When the encrypted packets are encapsulated inside other packets, the new IP headers identify the addresses of the Screens that protect the locations, not the hosts that originated the packets. Consequently, the network topology behind the Screens is never exposed.

When using encryption with tunneling in 64-bit mode, the destination address is incorrectly translated. 32-bit machines are unaffected. To set a 64-bit installed machine to boot in 32-bit mode, go into firmware (the "ok" prompt) and set the boot file to kernel/unix, by typing: ok setenv boot-file kernel/unix.

FIGURE 2-11 illustrates how tunneling affects the outside IP header of a packet traveling from Host A to Host B. Note that the encrypted packet containing the original data Host A sent to Host B is the same whether or not tunneling is used.

Figure 2-11 Effect of Tunneling on Contents of IP Headers

If you do not use a virtual private network (a tunnel) to transfer data between the two locations, the source and destination addresses on the outer IP header are the same as the source and destination addresses on the inner (encrypted) IP header: 1.1.1.10 and 2.2.2.10, respectively. Someone intercepting this packet would not be able to read its contents but could determine that hosts with IP addresses 1.1.1.10 and 2.2.2.10 reside behind the Screens protecting the two locations.

If you use a virtual private network to transfer data between the two locations, the Screen protecting Host A substitutes the IP address of its external interface (1.1.1.1) for the IP address of host A (1.1.1.10) in the Source Address field of the external IP header. Similarly, it substitutes the external IP address of the Screen at the other end of the tunnel (2.2.2.1) for the IP address of Host B in the Destination field. The local Screen then sends the packet through the nonsecure public network to the remote Screen.

When the remote Screen receives the packet, it strips off the encapsulation and decrypts the original packet from Host A. The remote Screen then reads the destination address from the original IP header of the decrypted packet and forwards the packet to Host B.

Note that, since the IP addresses behind the Screen are never exposed to hosts on the external Internet, the two locations do not need to assign externally valid IP addresses to hosts behind the Screens. As long as hosts behind the Screens do not need to communicate with hosts on the Internet, the two locations can use a shared IP address space, as shown in FIGURE 2-12.

Figure 2-12 Geographically Dispersed Network