A security policy is the collection of decisions an organization makes about network security and its stance regarding what network activities are permitted or denied. The most important aspect in installing and administering a firewall is a well-defined security policy.
A configuration is the union of one policy with the common objects to form a complete description of the behavior of one or more Screens. A policy is a named set of policy objects. For example, when the SunScreen software is first installed, there is one policy, named Initial. Common objects are data objects relevant to all policies. Object types are either named or ordered. Named common object types include address, screen, service, interface, certificate, and time objects. Ordered objects include filtering rules, NAT rules, administration access rules, and VPN gateway descriptions. Neither common objects nor rules include objects loaded into SKIP but they do include the reference from the certificate name in the common object registry to the internal identity used by SKIP.
Dynamic packet filtering allows 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 uses a set of ordered rules to filter packets. When you configure SunScreen, 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.
The centralized management group feature enables you to locate Screens at different points in the network to be managed with a standard set of objects through an Administration Station.
Centralized management reduces the overhead in configuring a set of firewalls. When firewalls in a set are configured differently, traffic does not flow through them properly. Centralized management avoids this problem because all the firewalls in the group share the same data.
The network address translation (NAT) feature makes it possible to have a Screen translate one set of addresses to another set. NAT is typically used:
To hide the internal topology of a network - Here the network's private (unregistered) addresses are translated to a set of public (registered) addresses. All traffic appears to come from this set of public address, rather than from the network's private addresses.
To use the public addresses assigned to a site efficiently - Many sites have a limited set of registered addresses assigned to them by the Internet service provider (ISP). With NAT you can use those addresses efficiently to support a large internal network. In this case, the addresses of the internal network are translated to the smaller set of registered addresses assigned by the ISP.
To prevent having to renumber host addresses when changing ISPs - NAT enables you to map your old public addresses to the new set of registered addresses assigned to you by your new ISP.
To use private or unregistered addresses on your internal network - The Internet Assigned Number Authority (IANA) has reserved the addresses ranges 10.0.0.0 through 10.255.255.255, 172.16.0.0 through 172.31.255.255, and 192.168.0.0 through 192.168.0.255 for use in private networks. NAT enables you to use these addresses in your internal network, yet still communicate with other networks by mapping those addresses into the registered addresses assigned to your site.
NAT works by modifying the address fields in the packet as it passes through the Screen. In addition to the address fields, the checksum and sequence number fields in the packet are modified. Certain protocols (such as FTP) also require that data within the packet containing address information be modified.
Organizations typically have offices in more than one location. SunScreen 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 a tunnel, or virtual private network, is set up between two or more locations, all data packets traveling from one location to the other are encrypted and wrapped inside other packets before they are sent over the public internetwork. Encrypting the packets guarantees that their contents will remain private; anyone capturing packets with the snoop program on network traffic between the two locations will be unable to read them. When the packets arrive at the remote location, they are unwrapped, 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.
High Availability(HA) enables you to deploy groups of Screens together in situations in which the connection between a protected inside network and an insecure 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. When an active Screen fails, 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 cluster.
SunScreen uses a combination of public-key and shared-key cryptography to encrypt and decrypt packets. Any traffic that passes between any two machines or other SKIP devices can be encrypted, while all traffic between a Screen and an Administration Station is encrypted.
SunScreen provides flexible logging of packets. This means that each primary and secondary Screen keeps a log of its traffic. Logs of the packets are kept on the Screen that passed or rejected the packets.
In an HA cluster only the active Screen logs network traffic. However, traffic destined for the active or passive HA machine itself may be logged according to the rule. This means that some passive Screens may log some traffic. This traffic is only the traffic to it, not the traffic that is going through it.
You can configure SunScreen to log a packet when it matches a rule or when it does not match any particular rule. Most frequently, packets matching DENY rules or packets that are dropped because they do not match any rule are logged. The action defined in a rule controls whether a packet is logged and what information about the packet is recorded.
Examining logged packets is useful when you are trying to identify the causes of problems during configuration or administration. You should also examine logs periodically for evidence of attempts to break into your network.
Each machine in an HA cluster logs what that system passed or rejected, as well as any locally processed nonpacket events.