Page 1
TONE /VPN R I R E W A L L E F E R E N C E U I D E I R EWA L L I R T U A L R I V A T E E T W O R K S...
Page 2
N:o 1334/2000 of 22 June 2000 setting up a Community regime for the control of exports of dual-use items and technology (as amended). Thus, the export of this Stonesoft software in any manner is restricted and requires a license by the relevant authorities.
NTRODUCTION In this section: Using StoneGate Documentation - 13 Introduction to Firewalls - 17 Introduction to StoneGate Firewall/VPN - 25 StoneGate Firewall/VPN Deployment - 33...
SING TONE OCUMENTATION Welcome to StoneGate™ High Availability Firewall/VPN solution by Stonesoft Corporation. This chapter describes how to use this Guide and related documentation. It also provides directions for obtaining technical support and giving feedback about the documentation. The following sections are included: How to Use This Guide...
This guide is divided into several sections. The chapters in the first section provide a general introduction to StoneGate firewalls. The sections that follow each include chapters related to one feature area. The last section provides detailed reference information in tabular form, and some guideline information.
Describes how to configure and manage the system step-by-step. Accessible through the Help menu and by using the Help button or the F1 key in any window or dialog. Available in the StoneGate Online Help Management Client and the StoneGate Web Portal. An HTML-based system is available in the StoneGate SSL VPN Administrator through help links and icons.
The certified platforms for running StoneGate engine software can be found at the product pages at http://www.stonesoft.com/en/products_and_solutions/products/fw/ Software_Solutions/. The hardware and software requirements for the version of StoneGate you are running can also be found in the Release Notes, available at the Stonesoft Support Documentation pages.
H A P TE R NTRODUCTION TO IREWALLS This chapter introduces and discusses the underlying security principles of firewalls in general. In this chapter we will discuss what firewalls are, which different types of firewalls there are, how they are used, what they are capable of, as well as what their possible weaknesses are.
Firewall Technologies This section presents an overview to the main firewall techniques, and explains how StoneGate uses them. The discussion here is limited to the traditional firewall component of a firewall system; the various additional inspection features that modern firewalls often incorporate are discussed separately.
Protocol Agents, when necessary, for enhanced security to inspect data all the way up to the application layer. The StoneGate firewall can also act as a packet filter for types of connections that do not require the security considerations of stateful inspection.
Illustration 2.2 Multi-layer Inspection Model By default, all StoneGate firewall Access rules implement stateful inspection, but the administrator can flexibly configure rules with simple packet filtering or an additional layer of application level security as needed. StoneGate firewalls apply application level inspection with or without proxying the connections, depending on what is required.
A firewall can have several different functions on a network. Although a firewall’s main function is to control network access, they can be used in several complementary roles depending on the firewall product used. This discussion concentrates on the main features available in StoneGate products.
(page 161). In addition to sending traffic to external content inspection, StoneGate Firewalls also integrate with StoneGate IPS. The firewalls accept blacklisting requests from the IPS and can therefore stop traffic that the IPS has detected to be harmful. For more information on integration with external StoneGate IPS components, see Blacklisting (page 175).
StoneGate firewalls have built-in support for clustering, which allows operating up to 16 physical firewall devices as a single unit. All units can actively handle traffic at the same time. No special configuration is required in the surrounding network to achieve this, as the whole implementation is achieved through basic networking standards.
H A P TE R NTRODUCTION TO TONE /VPN IREWALL This chapter gives you an overview of the StoneGate Firewall/VPN system’s architecture and how the system inspects traffic. The following sections are included: The StoneGate Security Platform (page 26) StoneGate Firewall/VPN System Components (page 27) Main Benefits of StoneGate Firewall/VPN...
The StoneGate Security Platform StoneGate Firewall/VPN is part of the StoneGate security platform, which is especially well- suited to complex and distributed network environments. In addition to firewalls and virtual private networking, the StoneGate security platform also provides intrusion detection and prevention.
The StoneGate system components and their roles are illustrated below. Illustration 3.2 StoneGate Security Platform Components One StoneGate Management Center can manage a large number of both Firewall/VPN and IPS engines. The StoneGate distributed architecture allows deploying the system components effectively in different network environments.
In addition to standard firewall features, the StoneGate Firewall/VPN system provides additional advanced features. Advanced Traffic Inspection StoneGate’s traffic inspection process is designed to ensure a high level of security and throughput. The firewalls’ policies determine when to use stateful connection tracking, packet filtering, or application-level security.
This way, the performance of the StoneGate system can be upgraded by simply adding new nodes to the cluster when necessary. Individual nodes can also be taken offline during business hours for maintenance purposes;...
You can also create QoS rules that read or write the priorities in DiffServ Code Point (DSCP) type of service (ToS) field, so that StoneGate is aware of the priorities set by other network equipment and other equipment is aware of the priorities set in StoneGate.
Management Center (SMC) with the secured inter-system communications ensure efficient integration of all system components. IP address blacklisting is a shared feature for StoneGate Firewall/VPNs and StoneGate IPS that allows blocking harmful traffic not just at the component that detects it, but also on other StoneGate engines on the connection path.
H A P TE R /VPN TONE IREWALL EPLOYMENT This chapter provides general guidelines for the StoneGate Firewall/VPN system deployment. It also illustrates a typical deployment with an example scenario. The following sections are included: Deployment Overview (page 34) Positioning Firewalls (page 35) Positioning Management Center Components...
Standard Intel-compatible servers. Search for the version-specific Hardware Requirements in the technical documentation search at http://www.stonesoft.com/en/support/. • As a VMware virtual host. More information can be found in the StoneGate Technical Documentation database, see document 2994: Installing and Activating StoneGate FW/VPN in VMWare ESX Server.
Positioning Firewalls The firewall is a perimeter defense, positioned between networks with different security levels. Firewalls generally control traffic between: • External networks (the Internet) and your internal networks. • External networks (the Internet) and DMZ (demilitarized zone) networks. • Between internal networks (including DMZs).
Access between networks can be network printers, copiers, etc. restricted based on the type of host. Firewall logs provide a record of network use and alerts can be configured for unusual connection attempts. Chapter 4 StoneGate Firewall/VPN Deployment...
Table 4.3 Internal Network Considerations for Firewalls (Continued) Description Implications on Firewalls Users can be considered trusted, but on various levels. The firewall authenticates users for access Users Authorized personnel. between internal networks that have different security levels. Installation at network choke-points often requires Varies from low to high.
Servers and Management Clients. These can be positioned flexibly according to need. Each Management Server can remotely manage a high number of both StoneGate Firewall and IPS components. Optionally, you can install one or more Management Servers as backups and one or more Web Portal Servers for view-only access to the system.
H A P TE R INGLE IREWALL ONFIGURATION A Single Firewall is a firewall that has only one firewall engine (instead of a cluster of two or more engines). The following sections are included: Overview to Single Firewall Configuration (page 42) Configuration of Single Firewalls (page 42) Example of a Single Firewall Deployment...
This chapter concentrates on those settings. Dynamic Firewall Interface Addresses StoneGate Single Firewalls support the use of DHCP and PPPoE to assign dynamic IPv4 addresses on the firewall’s network interfaces. Typically, a dynamic IP address is used in smaller sites with xDSL connections that have no static IPv4 address available for the firewall.
A Virtual Local Area Network (VLAN) is a logical grouping of hosts and network devices that allows creating several separated networks on a single physical link. To allow this separation, StoneGate supports VLAN tagging as defined in the IEEE 802.1q standard. One network interface can support up to 4094 VLANs.
Annex A are supported). ADSL Interfaces are only available on specific pre-installed StoneGate appliances that have an ADSL network interface card. Use the number of the ADSL port on the appliance as the Interface ID of the ADSL Interface.
authenticating all subsequent communications—a trust relationship between the engine and the Management Server is established. The one-time password expires at that time, since it is unnecessary from that point onwards. Task 8: Install a Firewall Policy After the firewall engine establishes contact with the Management Server, only the primary control interface with the Management Server is configured.
StoneGate Management Center has already been installed at the remote site, and the branch office administrator is now ready to install and configure the Single Firewall. The administrator: 1. Creates a Single Firewall element (Branch Office Firewall) and defines the Log Server at the remote site as its Log Server.
H A P TE R IREWALL LUSTER ONFIGURATION A Firewall Cluster is a group of firewall nodes that work as a single logical entity to share the load of traffic processing and provide redundancy, ensuring the availability of network services to the users.
Overview to Firewall Cluster Configuration A StoneGate Firewall Cluster consists of 2 to 16 nodes that function as a single entity. Clustering is a standard feature that you can activate on any StoneGate Firewall/VPN installation if you have two or more licensed engines.
Configuration of Firewall Clusters StoneGate firewalls are configured and managed centrally through the Management Server. The Firewall Cluster element represents the Firewall Cluster’s configuration on the Management Server. The main configuration options in the Firewall Cluster element include the settings related to network interfaces and clustering.
Network Interfaces and IP Addresses To work as replacements for each other, cluster members must have near-identical network interface configurations. A Physical Interface definition in the Management Client always represents a network interface definition on each node of the cluster. The table below explains the two types of IP addresses that you can add to a Physical Interface definition.
Clustering Modes There are several modes for how traffic can be directed to the cluster. The modes are explained in the table below. If necessary, refer to the documentation for the router, hub, or switch you are using for information on which mode is best in your environment. Table 6.2 Clustering Modes Mode Description...
Page 52
Illustration 6.2 Packet Dispatch CVI Mode 1. The dispatcher node for CVI 1 receives a new packet. 2. The dispatcher node either handles the packet itself or dispatches the packet to one of the other firewall nodes for processing according to the load-balancing filter. The packet is sent to the other node through the interface the packet arrived from.
A Virtual Local Area Network (VLAN) is a logical grouping of hosts and network devices that allows creating several separated networks on a single physical link. To allow this separation, StoneGate supports VLAN tagging as defined in the IEEE 802.1q standard. One network interface can support up to 4094 VLANs.
Task 4: Configure Physical or VLAN Interfaces There are two types of IP addresses that you can define on Physical Interfaces: Cluster Virtual IP Addresses (CVIs) and Node Dedicated IP Addresses (NDIs). You can define as many CVIs and NDIs per Physical Interface as you need. The two different IP address types are required due to the special requirements of clustering.
Task 5: Install the Firewall Engines During the engine installation, you map the network interfaces on the engine to the Physical Interface definitions created in the Management Client. See the Appliance Installation Guide delivered with the appliance for more information. During the installation, a basic initial configuration is activated and an initial contact between the Management Server and each engine is initiated.
Node State Synchronization State synchronization is essential for the following features: • Dynamic load balancing. • Transparent switchover of nodes in case of failure or maintenance. • Handling of related connections when a service (for example, FTP) opens multiple connections. Regular, timer-launched synchronization events are needed to synchronize state data and to avoid cutting connections in case of node failure.
Examples of Firewall Cluster Deployment The examples in this section illustrate the configuration of a Firewall Cluster with general steps on how each scenario is configured. Setting up a Firewall Cluster The administrators at the headquarters of Company A want to set up a Firewall Cluster. The cluster consists of two cluster nodes: Node 1 and Node 2.
Table 6.4 Cluster Interfaces Interface ID Type IP Address Comment NDI for Node1 10.42.1.1 Heartbeat NDI for Node2 10.42.1.2 Heartbeat 129.40.1.254 ISP B NDI for Node1 129.40.1.21 ISP B NDI for Node2 129.40.1.22 ISP B 212.20.1.254 ISP A NDI for Node1 212.20.1.21 ISP A NDI for Node2...
OUTING AND NTISPOOFING Routing is the process of defining through which network interface StoneGate forwards traffic from a source address to a destination address. Antispoofing is the process of defining which addresses are considered valid source addresses for the network(s) connected to each interface.
In addition to examining packets, a firewall has to determine how to route packets. For the most part, StoneGate automates the routing and antispoofing configuration. Much of the configuration is generated automatically based on the IP addresses of the network interfaces.
Page 61
Illustration 7.1 Example: The More Specific Destination is Considered First in Routing Interface 1 is always used for a destination of 192.168.0.202 because it has a Host element with the most specific address under it. The Antispoofing view defines the source addresses of traffic that are considered valid (not spoofed) for each interface of a Single Firewall and Firewall Cluster element.
Illustration 7.3 Both Interfaces are Considered Valid Both Interface 1 and Interface 2 are considered valid routes to Example Host (192.168.0.202) because the Host element is included under both interfaces. Multi-Link Routing for Single and Clustered Firewalls Multi-Link uses multiple network links (NetLinks) to balance the load of outbound traffic and ensure high availability of Internet connectivity.
Configuration Workflow The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Routing. Task 1: Add Router or NetLink A Router or a NetLink element represents a next-hop gateway that forwards packets to network(s) that are not directly connected to the Firewall element(s).
Examples of Routing The examples in this section illustrate some common uses of routing for Single Firewall and Firewall Cluster elements in StoneGate and general steps on how each scenario is configured. Routing Traffic with Two Interfaces Company A needs to route traffic to the Internet as well as to the internal Network B, which is not directly connected to the company’s Branch Office Firewall.
Routing Traffic to Networks That Use Same Address Space Company C’s network is connected to two partners: Network A and Network B. The Network A and the Network B partners use the same address space in their internal networks. Illustration 7.5 Policy Routing in Company C Router A Host 1...
H A P TE R IREWALL OLICIES Policy elements are containers for the lists of rules that determine how the firewall examines traffic. The policy elements include Firewall Template Policies, Firewall Policies, and Firewall Sub-Policies. The following sections are included: Overview to Firewall Policies (page 70) Configuration of Policy Elements...
Network Address Translation (NAT) Rules (page 109)). Policy Hierarchy The policy structure in StoneGate is a hierarchy based on templates, which allows you to: • Reuse rules without duplicating them. • Assign and enforce editing rights of different parts of a single policy to different administrators.
Page 71
Illustration 8.1 Connection/Packet Handling in a StoneGate Firewall 1. The firewall checks that the traffic is coming in through the correct interface as defined in the Routing and Antispoofing trees. 2. The firewall checks the current connection tracking information to see if the packet is part of an established connection (for example, a reply packet to a request that has been allowed).
4. If the packet is allowed as an existing connection or in an Access rule, the firewall checks that the packet is valid for the state of the connection. If not, the packet is dropped. • For example, a TCP connection must always begin with a SYN packet (as defined in the protocol standards), so the firewall checks that the first packet of a new connection is a valid SYN packet.
Page 73
Illustration 8.2 Rule Inheritance Firewall Template Policy A Firewall Sub-Policy Firewall Template Policy B Firewall Policy Rules: Firewall Template Policy A + Firewall Template Policy B + Firewall Sub-Policy + Firewall Policy In the illustration above, Firewall Template Policy A is the basis for Firewall Template Policy B, so Firewall Template Policy B contains all the rules defined in Firewall Template Policy A.
Default Elements The following policy elements are available by default: • The Default Template Policy contains the predefined IPv4 Access rules necessary for the firewall to communicate with the Management Center and some external components. All other Firewall Template Policies or Firewall Policies must be based on the Default Template Policy or a customized copy of it.
Illustration 8.3 shows what the same insert point looks like in a Firewall Template Policy and in the inheriting policy elements. The color of the insert point indicates whether the insert point has been added in the current Firewall Template Policy for inheritance to lower levels (orange) or whether it has been inherited from the higher-level Firewall Template Policy (green).
Illustration 8.4 A Firewall Sub-Policy in Use A Jump rule inserts the Firewall Sub-Policy, which is shown as an expandable section. The illustration above shows the same Jump rule in a policy in the collapsed and the expanded state. The rules of the Firewall Sub-Policy are shown on a grey background, because they can be edited only within the Firewall Sub-Policy itself, not in the Firewall Policy that uses the rules.
For those connections, you can disable connection tracking in the Access rules. This allows StoneGate to function as a simple packet filter for those connections, but it also prevents you from using some features that require the connection information from being applied to the connections.
Page 78
tracking is on. If done carelessly, turning connection tracking off reduces the benefits you gain from your firewall and may even weaken security. You may have other options: in some cases using the correct Protocol Agent helps. Note – Before disabling connection tracking, always check if there is a Protocol Agent for the protocol in question.
Page 79
Table 8.1 Connection Tracking Modes (Continued) Mode Protocol Explanation This mode can be used if you only want to allow TCP traffic that strictly adheres to TCP as defined in RFC 793. Other TCP traffic, for example, Transactional TCP traffic, is not allowed (see RFC 1644). The firewall checks that the TCP handshake proceeds according to the TCP definition.
Changes in the connection tracking mode affect how existing connections are handled at policy installation. When you upload a policy on an engine, the firewall checks if the existing connections are still allowed in the policy. If the connection tracking mode changes from Loose to Strict, existing virtual ICMP connections are only allowed if they began with a valid packet (for example, not with a response packet).
Company A has a firewall system administered by multiple administrators of various degrees of familiarity with networking, firewalls, and StoneGate. The administrators must often make very quick changes to respond to the needs of the company and attend to any problems detected.
StoneGate administrators. The StoneGate administrators decide to limit the privileges of the branch office IT staff so that they are not able to edit the policies of the firewalls at any of the other sites. The administrators: 1.
H A P TE R CCESS ULES Access rules are lists of matching criteria and actions that define how the firewall treats different types of network traffic. They are your main configuration tool for defining which traffic is stopped and which traffic is allowed. The following sections are included: Overview to Access Rules (page 84)
Additionally, Access rules select which allowed traffic is subjected to further inspection against the Inspection rules. In addition to traffic allowed by the Access rules, StoneGate automatically allows the following types of traffic with specific configurations: • DHCP requests and replies for an interface for which a DHCP server is enabled.
Configuration of Access Rules IPv4 Access rules are configured on the IPv4 Access tab, and IPv6 Access rules are configured on the IPv6 Access tab inside Firewall Policy and Template Policy elements. IPv4 Access Rules can additionally configured in Sub-Policy elements. You can create new Access rules in the Policy Editing View.
Page 86
The table below explains briefly what each Access rule cell does and which elements you can use in the rules. The cells are presented in the default order, but you can drag and drop them to your preferred order in your own Management Client. Table 9.1 Access Rule Cells Cell Explanation...
Default Elements There is a template called Default that contains the basic Access rules that allow communications between the StoneGate firewall on which the policy is installed and other system components. You must use the Default template as the basis for defining your own templates and policies, as it is not possible to create a new template at the highest level of the policy hierarchy.
Page 88
Illustration 9.3 Default Template Access Rules The illustration above shows the IPv4 Access rules included in the Default template. The insert point, where rules can be added in the inheriting Policy and Template Policy elements, is shown as a blank row near the end of the rule table. The rules above the insert point detail the various kinds of system communications.
Illustration 9.4 Default Template IPv6 Access Rules The illustration above shows the IPv6 Access rules included in the Default template. The insert point, where rules can be added in the inheriting Policy and Template Policy elements, is shown as a blank row near the end of the rule table. Configuration Workflow The following sections provide an overview of the configuration tasks.
Certain Services are associated with Protocols of the Protocol Agent type, which define more advanced inspection and handling for the connections. Additionally, the Protocol element identifies the protocol for the traffic for inspection against the Inspection rules (only some protocols are supported for this purpose on the firewall). For more information on Protocols and the network protocols that require Protocols of the type Agent, see Protocol Agents (page 123).
Page 91
Inspection rules. Used by rules with the Allow, Continue, or Jump action. Defines whether HTTP , HTTPS, IMAP , POP3, or SMTP traffic is inspected against a virus signature database on StoneGate UTM appliances. By default, the Antivirus options are undefined, which means that the rule Anti-Virus uses anti-virus options set in the previous matching Continue rule above.
Task 4: Select Logging Options By default, the rule’s Logging options are undefined, which means that the rule uses logging options that have been set in the previous Continue rule above. If there is no previous Continue rule, a Stored-type log entry is created. Logging for the closing of the connection can be turned on or off, or on with accounting information.
(page 77). Allowing System Communications The necessary communications between the firewall and other StoneGate components are allowed in the Default Template Policy. However, the Default template does not allow other StoneGate components to communicate through the firewall to some third StoneGate component.
Configuring Default Settings for Several Rules You may want to set default values for some settings in rules to avoid defining the same settings for several rules individually. The Continue action is used to set such default values. When a connection matches a rule with Continue as the action, some of the rule’s settings are written in memory but the matching continues until another rule that matches is found.
Illustration 9.5 Setting the Default Log Level Illustration 9.5, the default log level is set to Transient for any source, destination or service. All subsequent rules in this policy and any sub-policies log Transient by default. In this way, the administrator can collect information to display in the Logs view for all rules.
2. Create a Group element that contains the WWW server Host elements. 3. Create a Group element that contains the administrator PCs’ Host elements. 4. Configure an external authentication server for use with StoneGate. 5. Create User and User Group elements for the allowed external FTP users.
Page 97
6. Add IPv4 Access rules with the Allow action for access to the DMZs: Table 9.5 Access Rules for the DMZ Source Destination Service Users Authentication Action “Administrator “WWW Servers” Allow (Deep “HTTP” Service PCs” Group Group Inspection Off) “WWW Servers” Allow (Deep “HTTP”...
Example of Continue Rules Company B has decided to implement QoS Policies. The administrators want to set the QoS Class for traffic using a classification of high, medium, and low for all traffic depending on the sender. High priority is assigned to a small number of hosts in different networks, medium priority to one internal network, and low priority to all other hosts.
HA P T E R NSPECTION ULES Inspection rules define how the firewall looks for malicious patterns in traffic allowed through the Access rules and what happens when a certain type of pattern is found. The following sections are included: Overview to Inspection Rules (page 100) Configuration of Inspection Rules...
The firewalls can deep packet inspect HTTP , HTTPS, IMAP , POP3, SIP , or SMTP traffic just like a StoneGate IPS sensor. However, unlike the sensors, the firewall does not send any of the detected events to IPS analyzers for event correlation.
Configuration of Inspection Rules The firewall inspects traffic based on Situation elements, which contain the information about traffic patterns. Inspection rules are configured on the IPv4 Inspection tab inside IPS Policy and IPS Template Policy elements. Sub-Policies cannot contain Inspection rules. You can create new Inspection rules in the Policy Editing View and also in the Logs view based on one or more selected log entries.
The illustration below shows the Exceptions panel with some rules. Illustration 10.2 Exceptions Panel The main matching cell is the Situation that contains the actual patterns. The other matching cells are Logical Interface, Source, Destination, Protocol, and Time. The role of the other matching cells is to limit the scope of the rule to some specific traffic, for example, to take different action based on which host is the sender or receiver of traffic identified as malicious.
Example A Continue rule sets a User Response for Situation A, which matches the URL www.example.com. A different rule specifies Termination for Situation B, which also matches www.example.com. When the users access the URL, their connections are terminated without a User Response, because the User Response is set for Situation A and the traffic is terminated by Situation B.
Table 10.1 Exception Rule Cells (Continued) Cell Explanation Command for the firewall to carry out when a connection matches the rule. The action- specific Action Options define settings for anti-virus, connection termination and user responses. Action The Continue action can be used to set options for the Exceptions as explained in Setting Default Options for Several Inspection Rules (page 106).
Task 1: Activate Deep Inspection in Access Rules Typically, you introduce deep inspection after creating and testing initial Access rules. Firewalls can deep inspect HTTP , HTTPS, IMAP , POP3, SIP , and SMTP traffic. You must specifically activate deep inspection for the portion of traffic that you want to deep inspect. This is done in the Access rules.
Task 4: Eliminate False Positives As the Inspection rules are matched to traffic, there are always some occurrences of false positives (matches that are incorrect or irrelevant in your environment). By tuning the Inspection rules to the actual traffic and applications in your network environment, you can increase the relevancy of inspection results greatly.
StoneGate and general steps on how the scenario is configured. Eliminating a False Positive The StoneGate administrators in this example have just started using Inspection rules, installing a policy that includes only the rules defined in the Default Inspection Rules template.
HA P T E R (NAT) ETWORK DDRESS RANSLATION ULES Network address translation (NAT) means changing the IP address and/or port information in packets. Most often, NAT is used to allow internal hosts to communicate via networks where their actual address is not routable and to conceal the internal network structure from outsiders.
Overview to NAT Network address translation (NAT) changes the source or destination IP address or port for packets traversing the firewall. It is most often used to hide internal networks behind a single or just a few routable IP addresses on the external network. NAT is also often used to translate an external, routable destination address into the private internal address of a server.
Illustration 11.1 Static Source Translation Public Server Internal Network 129.40.1.100 192.168.1.101 Source packet Translated packet Translated packet Reply packet Illustration 11.1, the packet starts out with the source (SRC) and destination (DST) addresses (1). The firewall replaces the source address of the packets with a new source address (2).
11.3, a host on the Internet connects to a server on the internal network. The host connects to the external, public IP address (1). StoneGate then translates the destination address to the private IP address of the server on the internal network (2). The server sends its response back (3), and StoneGate automatically translates the source address back to the external IP address (4).
Configuration of NAT Address translation is configured as part of the Firewall Policy using NAT rules. NAT rules are configured on the IPv4 NAT tab inside Firewall Policy and Firewall Template Policy elements. Firewall Sub-Policies cannot contain NAT rules. Note – NAT rules are applied only after a packet matches an Access rule and is allowed by the firewall.
Page 114
The table below explains briefly what each NAT rule cell does (more information is included in the task flow further in this chapter). The columns are presented here in the default order, but you can drag and drop them to your preferred order in your own Management Client. Table 11.1 NAT Rule Columns Cell Explanation...
Considerations for Designing NAT Rules The basic design principle of NAT rules is the same as in Access rules: the rules are read from the top down, and more specific rules must be placed above more general rules that match the same traffic.
Using Policy Elements and Rules (page 77). NAT and System Communications If NAT is needed between StoneGate components, you must define Contact Addresses for the communications, so that the StoneGate components use the correct (NATed) address for contact when needed.
Contact Addresses are used in a NAT environment for communications of StoneGate components with each other and with some external components that function as a part of the system (such as a RADIUS server used for authenticating Administrators). Contact Addresses may be needed also for gateway-to-gateway and client-to-gateway VPNs.
In addition to source and destination translation, another main use for NAT is outbound load balancing. It is used in a Multi-Link configuration where StoneGate balances outbound traffic between two or more network connections. To be able to direct traffic to the faster connection, the firewall translates outgoing connections to an address from a pool assigned to each available NetLink.
In StoneGate, proxy ARP is handled automatically. Proxy ARP is enabled by default in the NAT cell in NAT rules for each translation type, although you have the option to uncheck it, if necessary.
• The administrators use the whole range of high ports ( for translating the 1024-65535) addresses in this case. • Return address translation is done automatically, so a single rule suffices to cover all (client) hosts that only open connections themselves, and do not need to accept new connections coming from external networks.
Page 121
Illustration 11.7 Company B’s Network Setup DMZ Network Internet Server A Router Firewall Server B The administrators first intend to just configure the servers to use the external (NAT) address of the other server as a destination and configure the related static destination NAT rule. However, they soon realize that the receiver would see the real source address in the communications and the replies would be sent directly, bypassing the firewall for the reply communications.
HA P T E R ROTOCOL GENTS Protocols of the Protocol Agent type are special modules for some protocols and services that require advanced processing. Protocol Agents can enforce policies on the application layer. The following sections are included: Overview to Protocol Agents (page 124) Configuration of Protocol Agents (page 125)
Overview to Protocol Agents Protocol Agents are software modules for advanced processing protocols that require special handling on the firewall due to their complexity, address information hidden in the data payload, etc. They can be used to extend the firewall’s Access rules with proxy-like application layer features.
NAT in Application Data Protocol Agents can be used to assist with network address translation (NAT) in the application data. For example, the H.323 conferencing protocol includes the source and destination address information in the data payload of the packets (as opposed to ‘normal’ traffic where all IP address information relevant to the communications is in the spaces reserved for this in the packet headers).
Protocol Agent”, the Protocol Agent does not have any options, but may still have a control for turning the Protocol Agent on/off in the Service. This control is meant for StoneGate IPS, which may require the Protocol element without the Protocol Agent features in some situations.
The FTP Protocol Agent inspects protocol validity. There are two selectable levels of inspection: loose (default) and strict. • In the loose mode, the Protocol Agent tries to identify information for opening the data connection. The loose mode is needed with some non-standard FTP applications. •...
ICMP Agent The Internet Control Message Protocol (ICMP) is used by the operating systems of networked computers to send error messages. There are no configurable parameters for this Protocol Agent. MSRPC Agent The MSRPC Protocol Agent is primarily meant for communications between Microsoft Outlook clients and a Microsoft Exchange server.
Services in Firewall Agent This Protocol Agent is intended for system services running on the firewalls. It is only intended for the system’s internal use. There are no configurable parameters for this Protocol Agent. SIP Agent The Session Initiation Protocol (SIP) agent can be used to handle multimedia connections that use SIP as their transfer protocol (such as voice over IP).
This agent has parameters you can set in the Service properties. Examples of Protocol Agent Use The examples in this section illustrate some common uses for Protocol Agents in StoneGate and the general steps on how each scenario is configured.
Logging URLs Accessed by Internal Users Company B has decided to keep track of which web pages the employees visit. In addition to logging the connections, the administrators also want to log URLs. The access is currently controlled by a simple rule that allows all outbound connections from the internal networks to the Internet regardless of the service, so the administrators decide to add the HTTP Protocol Agent in a Continue rule.
HA P T E R UTHENTICATION User authentication in the context of firewalls means requiring the users of services in your network to authenticate themselves (for example, by providing a username and password) before they are given access to some resources. The following sections are included: Overview to User Authentication (page 134)
User authentication requires creating user accounts. You can store the user accounts in StoneGate’s internal user database, or you can store it on an external server. StoneGate can connect to an external LDAP server (such as Microsoft Active Directory) so that you can use the user information for creating rules.
If you prefer, you can use the same server for storing and authenticating the users, for example, when you use StoneGate’s internal user database or a Microsoft Active Directory server for both tasks. Still, keep in mind that storing the user information and authenticating the users are two separate concepts with separate options.
LDAP server. When StoneGate’s internal LDAP database is used, the user and user group information is stored on the Management Server. Each firewall node stores a replica of the user database, and any changes to the main database are replicated immediately to the firewalls.
(page 287). External User Database Without Integration You can also leave StoneGate components completely out of user management if you set up an external authentication server. StoneGate relays the information it receives from the user to the authentication server and it is up to the external authentication server to check the supplied information and report back to StoneGate whether authentication succeeds or fails.
Default Policy Template in a rule that allows (authenticated) configuration download using legacy StoneGate VPN Clients (version 2.6 or older). To utilize the default rule with legacy VPN clients, store the user accounts in this User Group. More current StoneGate VPN Client versions do not require this type of rule.
Task 1: Create an External Authentication Server Element External authentication servers are configured using different types of Authentication Server elements. The server element is used for defining the information that StoneGate components need to contact the authentication server, such as the IP address and the shared secret.
It is not necessary to integrate an external database with StoneGate if you are using an external authentication server and you do not need to define different access rights to different users. In that case, you can create a special User element with the name *external* in the internal user database to represent any user that authenticates using the external authentication service.
Task 6: Define User Authentication in IPv4 Access Rules The IPv4 Access rules in a firewall policy can be configured to match only when the user is authenticated. With client-to-gateway VPNs, some form of authentication is always mandatory, but authentication can be required for non-VPN access as well. The authentication parameters are defined in the Users and Authentication cells.
Page 142
DHCP-assigned IP address with no other conditions. In the example rule set, users in StoneGate’s internal LDAP user storage do not gain any type of authenticated access. This is because those users cannot use the only authentication method that is included in the policy (IAS Authentication).
Examples of User Authentication The examples in this section illustrate some common uses for User Authentication in StoneGate and general steps on how each scenario is configured. Using the Internal Database for Authenticating Users Company A has a general office network and a separate network for servers that contain HR information, such as employee records and payroll information.
Company C is about to introduce remote StoneGate IPsec VPN Client access to their network. The administrators want to enhance the security of their authentication solution, as authentication is currently done using an external LDAP server and Telnet clients within the internal network.
Page 145
The administrators: 1. Create an Agent Host record for StoneGate in the RSA Authentication Manager server. 2. Create a VPN configuration in StoneGate with the default Hybrid Authentication selected as the authentication method for connecting clients. • Hybrid authentication, available for StoneGate IPsec VPN Clients, requires that the VPN...
HA P T E R HTTPS I NSPECTION The HTTPS Inspection feature decrypts HTTPS connections so that they can be inspected for malicious traffic, and then re-encrypts the traffic before sending it to its destination. The following sections are included: Overview to HTTPS Inspection (page 148) Configuration of HTTPS Inspection...
After decrypting the traffic, normal HTTP inspection and optionally virus scanning (requires the StoneGate UTM solution) are applied, and if the traffic is allowed to continue, it is re-encrypted before forwarding it. HTTPS inspection can only be applied to IPv4 traffic.
Configuration of HTTPS Inspection Illustration 14.1 Elements in HTTPS Inspection Server Protection HTTPS Service Credentials HTTPS Inspection Client Protection Exceptions Certificate Authority Access Rules Firewall The Server Protection Credentials and the Client Protection Certificate Authority are specified in the properties of the firewall that provides HTTPS Inspection. The firewall uses the private key and certificate stored in the Server Protection Credentials to decrypt traffic to and from HTTPS servers in the protected network for inspection.
Task 2: Create Client Protection Certificate Authority Elements If you want to inspect traffic between a client in the internal network and an external HTTPS server, you must create a Client Protection Certificate Authority element that contains the credentials the engine uses to sign the certificate it generates. You can import an existing private key and certificate, or generate a new private key and certificate.
Once HTTPS traffic has been decrypted, virus scanning can be done in the same way as for regular HTTP traffic (requires the StoneGate UTM solution). Any traffic that is allowed to continue after virus scanning is re-encrypted and sent to its destination. For more information about how...
1. Create a Client Protection Certificate Authority element and generate a new certificate and private key. Outside of StoneGate, the administrators add the Client Protection Certificate Authority they created to the list of trusted certificate authorities in the users’ Web browsers.
HA P T E R ILTERING Web filtering compares the URLs that end-users attempt to open to a list of URLs, which can be defined manually or through pre-analyzed and categorized addresses. When a match is found, you can configure the system to respond in the various ways allowed by Inspection rules.
Inspection Rules Firewall The Web Filtering feature is configured through Stonesoft-supplied Web Filtering Situations and/ or manual URL lists. The Inspection rules are configured in the same basic way as other Inspection rules. However, Web Filtering Situations can uniquely be configured to directly override other Situations to whitelist some URLs manually (as explained further in this chapter).
Default Elements There are default elements for the categories you can use in web filtering. These are represented by a specific type of Situation elements, which can be found under SituationsBy TypeWeb Filtering in the element tree and in the corresponding branch of the Rules tree in the Inspection rules.
The available categories may change when you activate a new dynamic update package, and be automatically enforced after the next policy upload (depending on the Rules tree settings). Examples of Web Filtering Allowing a Blocked URL The company is using category-based web filtering. Among other categories, the administrators have blocked end-users from viewing web sites categorized as “Questionable”...
HA P T E R IRUS CANNING A virus scanner compares network traffic against a virus signature database to search for viruses. If a virus is found, infected traffic is stopped or infected content is stripped out. The following sections are included: Overview to Virus Scanning (page 158) Configuration of Virus Scanning...
If an e-mail attachment is filtered out, a message is added to the e-mail notifying the recipient. Virus scanning is alternatively available (on all firewall/VPN engines) when you set up an external virus scanner and integrate it with StoneGate by configuring an external server as a content inspection server (CIS). See...
Task 3: Define the Content Not to Be Scanned For some content delivered through the HTTP or HTTPS protocol, the anti-virus scanning may not be feasible. For example, you may want to prevent videoconferences from being scanned for viruses to avoid any increase in latency. Exceptions to scanning can be made by matching the traffic with an Inspection rule that disables anti-virus in its options.
HA P T E R XTERNAL ONTENT NSPECTION Content inspection means analyzing FTP , SMTP , and HTTP traffic for malicious content. You can integrate an external content inspection server with the firewall. The following sections are included: Overview to Content Inspection (page 162) Configuration of Content Inspection (page 163)
This type of anti-virus checking is available directly on the firewall as well (as part of the StoneGate UTM solution), but an external content inspection server is a better option in medium to high throughput environments (see Integrated Scanning vs.
Configuration of Content Inspection FTP , SMTP , and HTTP traffic can be redirected to content inspection servers for inspection. This is done with the help of Protocol Agents. Illustration 17.2 Elements for Content Inspection Server Redirection CIS Server Protocol Service Firewall Firewall...
Configuration Workflow The following sections provide an overview to the configuration tasks. Detailed step-by-step instructions can be found in the Online Help or the Administrator’s Guide PDF, in the section called Policies. Task 1: Create a CIS Server Element The CIS Server element defines the content inspection server’s IP address and the services and ports that the content inspection server handles.
However, the redirection uses NAT, which may sometimes cause problems if you want the CIS to treat traffic differently based on IP address. In such cases, it may be necessary to configure the CIS server traditionally on the clients instead of using StoneGate’s redirection feature.
Example of Content Inspection The example in this section illustrates a common use for content inspection in StoneGate and general steps on how the scenario is configured. Inspecting Internal User’s Web Browsing and File Transfers The example company has decided to screen out non-work-related connections using an external content inspection server that can screen the HTTP and FTP connections that the company’s employees open to the Internet.
Page 167
5. Create the NAT rules for ensuring that NAT rules do not match to connections that are being redirected to the content inspection server and rules for translating the connections opened by the content inspection server for load-balancing the connections across the company’s Multi-Link network connections.
HA P T E R ITUATIONS Situation elements collect together the information that identifies and describes detected events in the traffic (or in the operation of the system). Situations contain the context information, that is, a pattern that the system is to look for in the inspected traffic. The following sections are included: Overview to Situations (page 170)
Overview to Situations Situations are elements that provide a way to define which traffic patterns and events you want to detect in your system with the firewall’s Inspection rules. The patterns and events are defined by selecting a Context for the Situation. The Context contains the information on the traffic to be matched, and the options you can set for the matching process.
Anti-Virus Contexts The Anti-Virus Contexts are used to detect viruses in HTTP , HTTPS, IMAP , POP3, and SMTP protocol traffic. You must have the StoneGate UTM solution to be able to use these Contexts for traffic inspection. Protocol-Specific Contexts The protocol-specific Contexts (the Contexts of the Application Protocols and Traffic Protocols type) are used to detect a particular characteristic in the network traffic.
The Release Notes of each dynamic update package list the new elements that the update introduces to your system. If your Management Server can connect to the Stonesoft website, you can view the release notes directly through the Management Client.
Vulnerabilities provide a short description of the event that has matched. Vulnerability information is included in dynamic update packages, so all Situations provided by Stonesoft that are related to a known vulnerability are linked to a Vulnerability element. When you create your own Situations, you can associate them with an existing Vulnerability or a custom Vulnerability element.
Example of Custom Situations The example in this section illustrates a common use for Situations in StoneGate and the general steps on how the scenario is configured. Detecting the Use of Forbidden Software Company A has a firewall that inspects all outgoing Web traffic against the Inspection rules. The use of instant messaging clients across the Internet is forbidden in the company.
HA P T E R LACKLISTING Blacklisting is a way to temporarily block unwanted network traffic either manually or with blacklist requests from a Sensor, Analyzer, or Management Server. Blacklisted connections are blocked for the duration of blacklist entries, after which the connections are again allowed.
Whitelisting Whitelisting means defining a list of IP addresses that must never be blacklisted. In Stonegate, whitelisting is achieved by following general Access rule design principles. Blacklisting applies only at the position of the blacklisting Access rule(s) in the policy. Traffic that has already been allowed or discarded before the blacklisting rules is not affected by blacklisting.
Configuration of Blacklisting Blacklisting is executed as defined in the IPv4 Access rules of the Firewall Policy, and automatic blacklisting requests are sent as defined in the Inspection rules of the IPS policy. Illustration 19.1 Blacklisting Configuration Firewall Blacklist Firewall Sensor A Analyzer Policy...
StoneGate IPS. Task 2: Define Analyzer-to-Firewall or Analyzer-to-Sensor Connections The Analyzer or Management Server connects to the StoneGate Firewall to send the blacklist requests. The Firewall policy’s Default template contains an Access rule that allows the blacklisting connections to the Firewall.
The blacklist can be sorted and filtered in the same way as logs. Examples of Blacklisting The examples in this section illustrate some common uses for blacklisting in StoneGate and the general steps on how each scenario is configured. Blacklisting Traffic from a Specific IP Address Manually Company A is using StoneGate Firewalls.
Page 180
To configure the automatic blacklisting for traffic from the attacker to the company’s servers, the administrators: 1. Create a new Ipv4 Access rule in the Firewall policy. The rule applies blacklisting and allows any component to send blacklist requests to the Firewall. 2.
HA P T E R UTBOUND RAFFIC ANAGEMENT You can use Multi-Link to distribute outbound traffic between multiple network connections and to provide high availability and load balancing for outbound traffic. The following sections are included: Overview to Outbound Traffic Management (page 184) Configuration of Multi-Link (page 184)
IP addresses are not supported for clustered firewalls in StoneGate. If you configure wireless Multi-Link on a Modem Interface of a single firewall, only Dynamic NetLinks are supported as Modem Interfaces always have dynamic IP addresses.
Multiple NetLinks are combined into an Outbound Multi-Link element. Outbound Multi-Link elements are the central elements used to configure load balancing for outbound traffic. Outbound load balancing is implemented by using the Outbound Multi-Link elements in the Firewall Policy’s NAT rules. Load Balancing Methods Load balancing can be based on either of two methods: Round Trip Time or Ratio.
Traffic is correctly balanced between active working links without probing if Round Trip Time balancing is used, since failed links are eliminated from use in the periodic round trip time checks. Despite the traffic finding its way to a working route, the actual working status of the links is not available to you or internally to the system unless you add NetLink probing to the configuration.
selected link fails. The same QoS class can be assigned to more than one NetLink in the same Outbound Multi-Link element to balance traffic through those selected NetLinks when those links are available. If you want to use QoS class to specify which traffic uses which NetLink, you must assign the QoS class to the traffic in an Access rule or with the QoS policies based on the DSCP codes in the traffic.
You can also configure Multi-Link with single firewalls by replacing one or more physical interfaces with Modem Interfaces and 3G modems. Illustration 20.3 Multi-Link Configuration with Two Modem Interfaces on Single Firewall 3G Modem 1 Modem Interface 1 ISP A Single Internet 3G Modem 2...
NetLinks. Examples of Multi-Link The examples in this section illustrate some common uses for Multi-Link in StoneGate and general steps on how each scenario is configured. Preparing for ISP Breakdown Company A wants to make sure their Internet connection remains available even when one ISP connection fails.
5. Select the QoS class for the ISP A NetLink and the ISP B NetLink in the Outbound Multi- Link element properties. No QoS class is assigned to ISP C. 6. Define the following NAT rule for outbound load balancing in the Firewall Policy: Source Destination Service...
HA P T E R NBOUND RAFFIC ANAGEMENT A Server Pool balances the load of incoming connections between a group of servers that function as a single entity. Additionally, Server Pools can be used to utilize dynamic DNS updates to disable access to a single server or a group of servers through non-working Multi- Link Internet connections.
The Server Pool has a single external IP address that the clients can connect to and StoneGate then uses NAT to distribute the incoming traffic to the different servers.
NetLinks. The client connects to one of these addresses and StoneGate then allocates the connection to one of the Server Pool members. If the first Server Pool IP address is unreachable, the client can connect to the Server Pool’s next IP address on a different NetLink (depending on the client application).
Configuration Workflow The following sections provide an overview of the configuration tasks. Detailed step-by-step instructions can be found in the Online Help of the Management Client and the Administrator’s Guide PDF, in the section called Routing. Task 1: Define Hosts First, you must introduce each server in the Server Pool into the system as a Host element so that the firewall has the IP addresses for sending the traffic.
Server Pools. Dynamic DNS (DDNS) Updates Optionally, StoneGate can automatically update dynamic DNS (DDNS) entries for the Server Pool according to the available NetLinks. The firewall engine removes the Server Pool IP addresses for NetLinks that are not available from the DNS entry, and adds the IP addresses back when the NetLink becomes available again.
Page 196
A Monitoring Agent runs as a service (port 7777/UDP by default) on the Server Pool member. The firewall queries the Monitoring Agent on each Server Pool member to check the status and load of the server. Illustration 21.4 Server Pool Monitoring Agents Provide Status Information Firewall Server 1 Server 2...
Automatic action can be configured based on the results of the test. When a test fails, an alert is sent to the StoneGate engines. Optionally, the agent can also take the server out of the Server Pool by changing its status from “OK” to “Excluded”. When a server is excluded from the Server Pool, all established and new connections are directed to other available servers in the pool and the excluded server does not process any connections.
3. Install a Server Pool Monitoring Agent on each server in the Server Pool and configure the Monitoring Agents to measure the load average on the server. They also set up a test that checks each server’s connectivity every 60 seconds and sends an alert if the test fails. 4.
HA P T E R ANDWIDTH ANAGEMENT RAFFIC RIORITIZATION Bandwidth management involves defining how the available network link bandwidth is divided between different types of communications to ensure important traffic is not delayed by less important traffic when the network is congested. Traffic prioritization is used either independently or in addition to bandwidth management to ensure quick delivery of time-critical communications, such as streaming audio or video.
StoneGate has its own internal traffic prioritization scheme, but StoneGate can also read and write DiffServ Code Point (DSCP) markers (type of service (ToS) fields). This allows you to integrate StoneGate with other network equipment that is implementing QoS management in your own or your ISP’s network.
If the traffic contains a DSCP code when the traffic enters the firewall, the firewall checks if the interface that the packets use to enter the firewall has a QoS Policy. If the QoS Policy defines a StoneGate QoS Class match for that code, the QoS Class indicated is applied to the traffic. See Communicating Priorities with DSCP Codes (page 206).
Default Elements There are three default QoS Classes in the system: High Priority, Normal Priority, and Low Priority. These are used in the default QoS Policy, Prioritize. The Prioritize QoS Policy is a sample policy that contains simple rules for prioritizing traffic according to the three default QoS Classes.
Packets that do not match a QoS rule are handled with priority 8 (middle of the scale) without any bandwidth guarantees or limits, and any DSCP markers in the traffic are preserved, but have no effect on how StoneGate handles the traffic. Configuration of Limits, Guarantees, and Priorities for Traffic...
QoS Class to any traffic that you can define in a single Access rule. If you choose to map existing DSCP codes in traffic to StoneGate QoS Classes, the same traffic must not match an Access rule that sets a QoS Class, since the Access rule overwrites the QoS Class that is assigned based on the DSCP code.
Using Bandwidth Management and Traffic Prioritization Bandwidth management and traffic prioritization are generally used for the following purposes: • To ensure the quality of service for time-critical communications during occasional traffic peaks. This may be necessary even if there is generally ample bandwidth available, since even very short periods of congestion may degrade the quality of some types of communications.
These priority values, set in your QoS Policies, are the only values that the system uses internally. If you want StoneGate to prioritize traffic based on DSCP markers, you must use the QoS Policies to map the DSCP priority values to the desired StoneGate priorities.
QoS Class in the Access rule overrides the QoS Class that is assigned based on the DSCP marker. When the packets are sent out through Physical Interface 2, StoneGate checks the QoS Policy assigned to this Physical Interface. In this QoS Policy, there is a rule that states that traffic with the assigned QoS Class will be marked with a DSCP marker specified in the rule, and the firewall overwrites the original DSCP marker before sending the packets onwards.
Prioritization The examples in this section illustrate some common uses for the bandwidth management features in StoneGate and general steps on how each scenario is configured. Ensuring Quality of Important Communications In this example, Company A has two offices, one in Italy and one in France. The company has decided to replace most conventional phone lines with VoIP telephony to cut down on cost.
ISPs for one 512 kbps link from each. None of the communications are especially time-critical, so the company decides not to prioritize the traffic. Then the StoneGate administrators: 1. Create a new QoS Policy and two new QoS Classes, called VPN and Extranet.
However, the StoneGate administrators suggest a different approach: limiting the portion of the bandwidth that the non-essential traffic can use so at least some of the employees can still listen to Internet radio while the business communications are guaranteed the bandwidth they need.
HA P T E R VERVIEW TO This chapter provides an introduction to Virtual Private Networks (VPN) and the IPsec standards on which VPNs in StoneGate Firewall/VPN are based. The following sections are included: Introduction to VPNs (page 214) IPsec VPNs (page 215) VPN Topologies...
Typically, VPNs are used to secure connections between the corporate LAN and a branch office, a supplier or partner office, telecommuters, or mobile workers. The gateway devices handling a VPN (including the StoneGate firewalls) are called security gateways (SGWs) when building VPNs. There are two types of IPsec VPNs you can build: •...
IPsec VPNs StoneGate uses the IPsec protocol standards to implement VPNs at the IP network layer. This means that IPsec allows any IP traffic to be transported in the VPN regardless of which higher- level protocol the traffic uses on top of IP; hosts can communicate through the VPN as if it was a normal link without the need for application-specific configurations on the gateway device.
The standards also have a provision to use a combination of ESP and AH, but this option does not provide significant security improvements in the type of VPNs StoneGate establishes, and is not supported in the current version of StoneGate.
VPNs. StoneGate always uses the tunnel mode. • The transport mode does not encapsulate the packets. The IPsec standard provides the transport mode for host-to-host communications and it is not used in StoneGate. VPN Topologies StoneGate VPN tunnels can be defined using different topologies: •...
Page 218
Illustration 23.2 Full Mesh VPN Topology Central Gateway Central Gateway Central Gateway Central Gateway In a full-mesh topology, all security gateways are defined as central gateways so that each gateway can establish, when needed, a VPN tunnel with the other gateways in the VPN. This allows VPN communications from any one site to any other site.
Page 219
Illustration 23.4 Hub VPN Topology Satellite Gateway Satellite Gateway Satellite Gateway Central Gateway The hub topology simplifies VPN client use if the clients connect to several gateways. It can also make setting up gateway-to-gateway VPNs easier, especially if the satellite gateways are 3rd party devices.
HA P T E R VPN C ONFIGURATION A virtual private network (VPN) extends a secured private network over untrusted networks by encrypting connections so that they can be transported over insecure links without compromising confidential data. For this purpose, the devices that create the VPN check the identity of the other parties by the way of authentication.
Windows platforms. You can alternatively use some third party IPsec- compatible VPN client, but third party clients do not support all features offered by StoneGate. VPN clients cannot connect directly to firewalls that have a dynamic IP address. Instead, VPN clients can connect through a central gateway that is used as a hub that forwards the connections to the non-compatible gateways using a gateway-to-gateway VPN.
Page 223
Illustration 24.1 Elements in the VPN Configuration (Excluding Certificate-Related Elements) The three main points of VPN configuration are (as indicated by the numbers in the illustration above): 1. The Gateway element sets VPN-related settings particular to one Firewall/VPN device. Each Gateway element can be used in several VPNs. The Gateway element refers to the following other elements: •...
VPN in some configurations. Under Gateways, there is a predefined IPsec Client gateway element that is used to represent VPN clients, including any StoneGate and third party VPN clients. Note that you can change the Gateway Profile associated with this default element.
The special predefined IPsec Client Gateway element represents all types of VPN clients in client-to-gateway VPNs. When you set up a client-to-gateway VPN with StoneGate VPN clients, the IPsec Client element must always be used. In most cases, we recommend using the element with third party VPN clients as well.
VPNs, you can freely select between pre-shared keys and certificates as the authentication method. In client-to-gateway VPNs, certificates are always needed when StoneGate IPsec VPN clients are involved. However, if you use the hybrid authentication method with StoneGate IPsec VPN clients, only the gateway needs a certificate.
Tunnels are generated based on the overall topology (from each central gateway to all other gateways). You can further adjust the tunnels generated to limit which gateways and end-points form tunnels with each other, and change some of the properties for tunnels between two particular gateways or end-points, such as the VPN Profile used.
Task 9: Configure VPN Clients and External Gateway Devices If you use the StoneGate IPsec VPN Client, the VPN configuration you create in the Management Client is also used for creating the configuration for the VPN clients. The VPN clients then download the settings from the VPN gateway(s) either manually or automatically whenever there are relevant changes.
UDP packets to allow NAT modifications but prevent the encapsulated VPN traffic from being modified by NAT. StoneGate IPsec VPN clients also support TCP tunneling, which works similarly, but allows also forwarding the traffic through any port you define to allow the traffic to pass a filtering device that is not under your control.
FIPS Mode If your organization is required to follow FIPS encryption standards, some of the options presented in the tables that follow are not available in your system. See the StoneGate Common Criteria User’s Guide for more information. GOST-Compliant Systems If your organization is required to follow GOST encryption standards, the options in your system are mostly different from those presented in the tables that follow.
Table 24.2 Supported Message Digest Algorithms (Continued) Algorithm Description Message-Digest algorithm 5, a 128-bit hash algorithm (also referred to as HMAC-MD5). Available for checking the integrity of the IKE negotiations and IPsec traffic. Most IPsec-compliant VPN devices still support this algorithm, but support may become less common in the future.
Most IPsec-compliant VPN devices support this method. Reference: RFC 2451. Uses up to 448-bit keys. StoneGate uses 128-bit keys by default, but accepts up to 448-bit keys if requested by the other gateway. Blowfish Many IPsec-compatible VPN devices do not support this method.
Administrators must also remember to renew the pre-shared keys periodically to maintain a high level of security. StoneGate includes tools for generating sufficiently long, random pre-shared keys for VPN components. The keys are automatically transferred to any Internal Security Gateway devices that need them using the secure system communications channel.
LDAP or HTTP (depending on what the certificate specifies). If all defined CRL servers are unreachable, the certificates are considered invalid until the CRL can be checked. You can set up StoneGate to access to CRL servers directly or use the OCSP protocol. Internal VPN Certificate Authority The Management Center has an internal VPN Certificate Authority Internal IPsec CA for creating self-signed certificates.
Configuring VPNs with External Gateway Devices In StoneGate, the term ‘external’ refers to any VPN gateway that is not controlled by the Management Server (and the same administrative Domain) on which you are configuring the gateway element. Often, external gateway devices are at a partner organization, not under your control, and not StoneGate firewall/VPN devices.
The IP addresses accessible through each Gateway are a commonly mismatched setting. In StoneGate, the IP addresses included in the VPN are defined as separate Site elements for the Internal and External Security Gateway elements. An associated setting is the SA (security association) granularity setting, which defines whether a new tunnel is established per each communicating host or per each network;...
VPN under any conditions. StoneGate IPsec VPN clients can also use Multi-Link. If one of the gateway’s links fails, the client automatically connects to the next available NetLink.
Creating a VPN Between Three Offices Company A has a central site and two remote offices, each with their own StoneGate Firewall/ VPN device. The company needs secured communications links between the remote offices and the central site to allow access to various services, such as file servers, located at the central site.
The administrators need to add VPN client access to the existing VPN infrastructure. The administrators decide to use the StoneGate IPsec VPN client, since all their users are running a compatible Windows operating system. As the authentication method, the administrators decide to use passwords stored in the Management Server’s internal database.
The administrators include the Gateway contact information in the package so that the users do not need to enter it manually even when they use the StoneGate IPsec VPN client for the first time.
Page 241
3. Create an External Security Gateway element “Partner Gateway” for the partner’s VPN device using the internal IP address as the VPN end-point, and adding the external (translated) IP address as the Contact Address for the Location created in the previous step.
P P E N D I X OMMAND OOLS This appendix describes the command line tools for StoneGate Management Center and the engines. The following sections are included: Management Center Commands (page 246) Engine Commands (page 254) Server Pool Monitoring Agent Commands...
-h or -help displays information on using the script. -v displays verbose output on the command execution. Example (exports logs from one full day to a file using a filter): sgArchiveExport login=admin pass=abc123 i=c:/stonesoft/stonegate/data/archive/firewall/ year2009/month12/day01/ f=c:/stonesoft/ stonegate/export/MyExportedFilter.flp format=CSV o=MyExportedLogs.csv Appendix A...
Page 247
Domains. If the Domain is not specified, the Shared Domain is used. Creates a new certificate for the Management Server to allow secure communications between the StoneGate system sgCertifyMgtSrv components. Renewing an existing certificate does not require changes on any other system components.
Page 248
<IP address> command if you change the Management Server’s IP address. Restart the Management Server service after this command. Starts a locally installed StoneGate Management Client. sgClient Creates an unrestricted (superuser) administrator account. The Management Server needs to be stopped before running this sgCreateAdmin command.
Page 249
Database Replication option is selected in the standby Management Server’s properties). Imports StoneGate Management Server database elements from a StoneGate XML file. When importing, existing (non-default) elements are overwritten if both the name and type match. Host specifies the address of the Management Server. If the sgImport ...
Page 250
Description Imports and exports a list of Users and User Groups in an LDIF file from/to a StoneGate Management Server’s internal LDAP database. To import User Groups, all User Groups in the LDIF file must be directly under the stonegate top-level group (dc=stonegate).
Page 251
The file location is displayed on sgInfo the last line of screen output. Provide the generated file to Stonesoft support for troubleshooting purposes. Located in <installation directory>/bin/install. Creates a new Log Server configuration if the configuration file has been sgReinitializeLogServer lost.
Page 252
[port PORTNUM] [login LOGINNAME] PORT is the Management Server’s Management Client port [pass PASSWORD] number (by default, 8902). LOGINNAME is a StoneGate administrator account for the login. PASSWORD is the password for the administrator account. Appendix A Command Line Tools...
Page 253
The e parameter defines the filter that you want to use for filtering the log data. Type the name as shown in the Management Client. The f parameter defines the StoneGate exported filter file that you want to use for filtering the log data.
The commands in the following two tables can be run on the command line on the analyzer, firewall, and/or sensor engines. SOHO firewalls do not provide a command line interface. Table A.2 StoneGate-Specific Command Line Tools on Engines Engine Command...
Page 255
--append=kernel options parameter defines any other boot options to add to the configuration. --help parameter displays usage information. apply command applies the specified configuration options. Use this only if you want to return a StoneGate appliance to analyzer, its factory settings. firewall, sg-clear-all Clears all configuration from the engine.
Page 256
Table A.2 StoneGate-Specific Command Line Tools on Engines (Continued) Engine Command Description Type Deletes VPN-related information (use vpninfo command to view the information). Option -d (for delete) is mandatory. -u deletes the VPN session of the named VPN client user. You can enter the user account in the form <username@domain>...
Page 257
Table A.2 StoneGate-Specific Command Line Tools on Engines (Continued) Engine Command Description Type Used for reconfiguring the node manually. --boot option applies bootup behavior. Do not use this option unless you have a specific need to do so. sg-reconfigure analyzer,...
Page 258
--help option displays usage information. The table below lists some general operating system commands that may be useful in running your StoneGate engines. Some commands can be stopped by pressing Ctrl+c Table A.3 General Command Line Tools on Engines...
Server Pool Monitoring Agent Commands You can test and monitor the Server Pool Monitoring Agents on the command line with the commands described in the table below. Table A.4 Server Pool Monitoring Agent Commands Command Description Allows you to test different configurations before activating them. -d Don’t Fork as a daemon.
Page 260
Table A.4 Server Pool Monitoring Agent Commands (Continued) Command Description Sends a UDP query to the specified host and waits for a response until received, or until the timeout limit is reached. The request type can be defined as a parameter. If no parameter is given, status is requested.
P P E N D I X EFAULT OMMUNICATION ORTS This chapter lists the default ports used in connections between StoneGate components and the default ports StoneGate uses with external components. The following sections are included: Management Center Ports (page 262) Firewall/VPN Engine Ports...
TCP: 8902-8913 8914-8918 + 3021 (Log Server Certificate Request) Illustration B.2 Default Destination Ports for Optional SMC Components and Features External LDAP Server TCP: Stonesoft’s Update Service External RADIUS Server UDP: TCP: Management Server 1812 Server Web Portal Secondary Server...
Page 263
The table below lists all default ports SMC uses internally and with external components. Many of these ports can be changed. The name of corresponding default Service elements are also included for your reference. For information on communications between SMC components and the engines, see the separate listings.
Server Update packages, engine upgrades, Stonesoft Management and licenses from 443/TCP HTTPS servers Server update.stonesoft.com and smc.stonesoft.com. Log data export to syslog servers. Syslog (UDP) 514/UDP , , Syslog Server Log Server The default ports can be modified in 5514/UDP [Partial match] the LogServerConfiguration.txt file.
Page 265
Illustration B.4 Destination Ports for Basic SOHO Firewall Engine Communications SOHO Firewall NTP Time Server Log Server UDP: TCP: Manage- 8923 ment Server TCP: 8922 8924 Illustration B.5 Default Destination Ports for Firewall/VPN Engine Service Communications LDAP Server RADIUS Server TACACS+ DNS Server Server...
Page 266
The table below lists all default ports StoneGate Firewall/VPN uses internally and with external components. Many of these ports can be changed. The name of corresponding default Service elements are also included for your reference. Table B.2 Firewall/VPN Default Ports...
Page 267
TACACS+ 49/TCP Firewall TACACS+ authentication requests. TACACS (TCP) server 500/UDP , 2746/UDP VPN traffic. Ports 2746 and 4500 VPN gateways (StoneGate Firewall may be used depending on ISAKMP (UDP) gateways only), encapsulation options. or 4500 UDP . Firewall/VPN Engine Ports...
Page 268
Table B.3 SOHO Firewall Default Ports Listening Contacting Service Element Port/Protocol Service Description Host Hosts Name SOHO Firewall 500/UDP VPN gateway Internet Key Exchange (IKE) for IPsec. ISAKMP (UDP) engine Configuration and status Management 8922/TCP SOHO Firewall communication to the Management SG SOHO Control Server Server.
P P E N D I X REDEFINED LIASES This appendix lists the predefined Aliases that exist in the system. The predefined Aliases are used in the Firewall’s default system policies. Some of them may be useful when you create your own Firewall and IPS rules.
The DHCP servers defined for assigning virtual IP addresses to VPN VPN Clients clients. System Aliases System Aliases are non-editable Aliases created by StoneGate. The System Aliases are preceded with two $$ characters. Table C.2 lists the definitions of all the System Aliases. These Aliases are used in the firewall’s default system policies.
Page 271
Table C.2 System Aliases (Continued) System Alias Description $$ Local Cluster (DHCP Interface Addresses) All DHCP-assigned IP addresses of the engine. $$ Local Cluster (NDI addresses only) All NDI addresses of all nodes in the cluster. $$ Local Cluster (NDI for heartbeat addresses Heartbeat NDI addresses of all nodes in the cluster.
EGULAR XPRESSION YNTAX Regular expressions are used to define patterns in traffic for custom Situations, which can be used in Inspection rules in StoneGate Firewall and IPS. The following sections are included: Syntax for StoneGate Regular Expressions (page 274) Special Character Sequences (page 276) Pattern-Matching Modifiers...
Syntax for StoneGate Regular Expressions StoneGate custom Situations are often defined as text strings using regular expression patterns for matching byte sequences in network traffic. The expression matching starts always at the beginning of the traffic stream. For this reason, ‘...
Page 275
Table D.1 StoneGate Regular Expression Syntax (Continued) Sequence Description Example Used in bracket expression to match any character of the defined class. The <class> can be: alnum [0-9A-Za-z], alpha ‘[[:digit:]]’ matches any digit, e.g. [A-Za-z], ascii (ascii char), blank (space or tab), [:<class>:]...
Use the “ ” quantifier where possible, instead of the ‘*’ and ‘+’ bounds. Variables {num,max} can also be used to break down the pattern to smaller chunks as described in Bit Variable Extensions (page 278). Illustration D.1 provides an example regular expression. Illustration D.1 Example regular expression # This expression matches any of the following patterns in the traffic: # ‘/bin/{ash|bash|csh|ksh|sh|tcsh}’...
“C:\x0Cile.exe” string where \x0C is the formfeed “\f”. Pattern-Matching Modifiers The StoneGate regular expression syntax has Perl-like extensions. The pattern-matching modifiers are extensions that can be used to control the matching process in more detail. The modifiers are enabled with and disabled with a minus (?<modifiers>)
Table D.4 Pattern-Matching Modifiers (Continued) Sequence Description “Allow comments mode” When enabled, anything after the hash character ‘# ’ is considered as a comment and not included in the matching process. (?C) When disabled, the hash character ‘# ’ and anything following are used in the matching process.
Page 279
Each variable is unique within the Situation or Situation Group where the variable is used. The name of a Situation variable can be anything consisting of alphanumeric and underscore characters [A-Za-z_0-9]. The variable name must not begin with a digit. The variable has a boolean value that can be either 0 or 1.
Variable Expression Evaluation Variable expression evaluation is an extension to regular expression syntax that provides the ability to parse values from the input stream, perform arithmetic operations, detect large blocks of data, and use variable larger than one bit. This allows you to create more precise and reliable Situations in cases that are difficult with the traditional regular expression syntax.
Page 281
Table D.7 Operations on Expression Results (Continued) Sequence Description Divides the value of <var> with the value returned by expression <expr> <var> /= <expr> and sets the result to variable <var>. Divides the value of <var> with the value returned by expression <expr> <var>...
Table D.7 Operations on Expression Results (Continued) Sequence Description Performs OR with if expressions <expr_a> and <expr_b> and returns the <expr_a> || <expr_b> result. Increase value of variable <var> by one. <var>++, ++<var> Decrease value of variable <var> by one. <var>--, --<var>...
Table D.9 ASCII Data Variable Expressions (Continued) Sequence Description The actual number of parsed digits is available in the variable. parse_int(<is available>) Parse ASCII octal value. <length> is the maximum number of the characters to parse. The actual number of parsed digits in the variable parse_oct(<length>) $parse_length@32.
D.5), except that the variable’s value is not user-changeable. Table D.12 System Variables Sequence Description The major version number of the StoneGate engine. $major The minor version number of the StoneGate engine. $minor The patch level number of the StoneGate engine.
The syntax for the independent subexpression is as follows: Table D.13 Independent Subexpression Syntax Sequence Description <regular_expression> is a normal StoneGate regular expression (?><regular_expression>) launched independently from the main regular expression. <expression> is a comparison expression that is evaluated before the independent subexpression <regular_expression>...
Parallel Matching Groups StoneGate allows you to set different regular expressions to be matched in parallel groups within one Situation Context. Normally, manual situation group definitions are not needed and StoneGate automatically compiles all your custom Situations in the same group (group 0).
ERVERS This section lists the StoneGate-specific LDAP classes and attributes that you add to the schema of external LDAP servers’. The StoneGate specific attribute and class names start with “sg”. The classes are listed in Table E.1. Table E.1 StoneGate Specific LDAP Classes...
Page 288
Table E.2 StoneGate Specific LDAP Attributes (Continued) Attribute Related Classes Description sgpassword sguser MD5 message digest hash of the user password. sgpresharedkey sguser IPsec PreSharedKey for the user account. sgsubjectaltnames sguser IPsec certificate SubjectAltNames for the user account. sgvirtualip sggroup, sguser Virtual IP allocation allowed for the user.
Page 289
SNMP T RAPS AND StoneGate Firewall/VPN and IPS engines can send SNMP traps on system events. The traps are configured using SNMP Agent elements. Additionally, the Tester entries can be configured to send SNMP traps. The SNMP traps are listed in Table F.1.
(Table F.3) • STONESOFT-NETNODE-MIB (Table F.4). The StoneGate Firewall/VPN MIB files can be downloaded from the Stonesoft website at http:// www.stonesoft.com/. The StoneGate Firewall/VPN also supports objects in the following standard MIBs: • IF-MIB (RFC 2863 and RFC 2233) (Table F.5)
Page 291
Table F.4 STONESOFT-NETNODE-MIB Objects (Continued) Object Name Object Description in MIB nodeTestResult The most recent result of the nodeTest nodeTestResultTime The timestamp of the most recent result of the nodeTest Table F.5 IF-MIB Supported Objects Object Name Object Description in MIB The desired state of the interface.
Page 292
Table F.5 IF-MIB Supported Objects (Continued) Object Name Object Description in MIB The 64-bit wide number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. This object is a 64-bit version of ifInUcastPkts.
Page 293
Table F.5 IF-MIB Supported Objects (Continued) Object Name Object Description in MIB The 32-bit wide number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses.
Page 294
Table F.5 IF-MIB Supported Objects (Continued) Object Name Object Description in MIB The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed. If ifAdminStatus is down(2) then ifOperStatus is down(2). If ifAdminStatus is changed to up(1) then ifOperStatus changes to up(1) if the interface is ready to transmit and receive network traffic;...
Page 295
Table F.5 IF-MIB Supported Objects (Continued) Object Name Object Description in MIB An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object must contain the nominal bandwidth.
Page 296
Table F.6 IP-MIB Supported Objects (Continued) Object Name Object Description in MIB The number of ICMP messages which this entity did not send due to problems discovered within ICMP such as a lack of buffers. This value must not include errors icmpOutErrors discovered outside the ICMP layer such as the inability of IP to route the resultant datagram.
Page 297
Table F.6 IP-MIB Supported Objects (Continued) Object Name Object Description in MIB The number of IP datagram fragments that have been generated as a result of ipFragCreates fragmentation at this entity. The number of IP datagrams that have been discarded because they needed to be ipFragFails fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set.
Page 298
Table F.6 IP-MIB Supported Objects (Continued) Object Name Object Description in MIB The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of ipOutDiscards buffer space).
Page 299
Table F.7 SNMP-USER-BASED-SM-MIB Objects (Continued) Object Name Object Description in MIB The status of this conceptual row. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the usmUserStatus column is 'notReady'. In particular, a newly created row for a user who employs authentication, cannot be made active until the corresponding usmUserCloneFrom and usmUserAuthKeyChange have been set.
Page 300
Table F.8 SNMPv2-MIB Supported Objects (Continued) Object Name Object Description in MIB The total number of GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest- PDUs, SetRequest-PDUs, and InformRequest-PDUs delivered to the SNMP entity which were silently dropped because the size of a reply containing an alternate snmpSilentDrops Response-PDU with an empty variable-bindings field was greater than either a local constraint or the maximum message size associated with the originator of...
The other CVI modes are provided mainly for backward compatibility. The following sections are included: The General Features of Multicasting (page 302) IP Multicasting Overview (page 302) Internet Group Management Protocol (page 303) Ethernet Multicasting (page 304) Multicasting and StoneGate (page 304)
The General Features of Multicasting Multicasting differs in certain important respects from unicasting and broadcasting as a transmission technique. A distinction can be made between multicasting traffic at the network layer (based on special class D IP addresses) and at the data link layer (based on multicast MAC addresses).
address of an established permanent group will persist even if the group would not have any members at a given time. The transient groups will cease to exist as soon as they no longer have member hosts, and the assigned multicast address is released. See, for example, http://www.iana.org/assignments/multicast-addresses for a list of...
After distinguishing between network layer multicasting and data link layer multicasting, we can now have a look at how Stonesoft’s StoneGate high availability firewall uses multicasting and unicasting. When using clustering technology, the clustered firewall nodes share a common unicast IP address, which is called a CVI (cluster virtual IP address).
StoneGate firewall clusters in different types of network environments. The method can be selected based on the surrounding network devices. Unicast MAC configuration can be used with hubs and with switches that support sending a specified unicast MAC address to several ports at the same time.
Illustration G.1 CVI with Unicast MAC Node 1 Node 2 Node 3 Multicast MAC In case it is not feasible to use a switch that works in unicast mode with clusters, a shared multicast MAC may be defined for the cluster nodes. Most switches support this mode, however, not all switches in the same virtual LAN (VLAN) need to be configured.
To prevent this, you can either configure the router to send this traffic only to the cluster ports or define the router’s access control list (ACL) to drop all incoming packets with the cluster’s multicast MAC. Multicasting and StoneGate...
L O S S A R Y Access Control List A list of Elements that can be used to define the Elements that an administrators with restricted permissions can access. See also Administrator Role Granted Element. Access Rule A row in a Firewall or IPS policy that defines how one type of IPv4 connection is handled by providing matching criteria based on the source, destination, and protocol information.
Page 310
See also Alert Escalation. Alert Server A StoneGate Management Center component that handles receiving and handling of Alerts. The Alert Server cannot be installed separately, it is integrated in the Log Server installation. Alias Element that can be used to represent other network elements in configurations.
Page 311
Analyzer 1) A device in the StoneGate IPS system that analyzes the log information from Sensors according to its policy to find patterns, so that separate log entries can be combined together.
Page 312
(proved who they are), they are authorized (given permission) to perform certain actions. Balancing Mode A StoneGate cluster mode that attempts to divide the traffic as equally as possible between the online engines participating in the cluster. Confer to Standby Mode (page 333).
Page 313
A way of organizing elements and policies to display a specific subset at a time when configuring a large StoneGate system in the Management Client to make it easier to find the relevant elements when configuring the system. For example, a Managed Service Provider (MSP) who manages networks of several different customers can add a customer-specific category to each element and policy to be able to view one customer’s elements and policies at a time.
Page 314
(authenticated and encrypted) connection through insecure networks. Cluster A group of devices, or nodes, that share a given work load. In StoneGate, you can cluster Firewalls and Sensors to share the load and provide redundancy, allowing, for example, scheduled maintenance that takes one node out of service without interrupting services to the users.
Page 315
Contact Address The IP address that is needed to contact a device performing a function in the StoneGate Management Center when there is NAT (Network Address Translation) being performed in between the two devices and thus the actual IP address assigned to the network interface cannot be used directly.
Page 316
Default Element Element that is present in the system at installation, or is added to the system during an upgrade or from a Dynamic Update (Package). Default elements cannot be modified or deleted by administrators, but they may be modified or deleted by dynamic update packages or upgrades.
Page 317
Rules. Element A StoneGate object representing the equipment in your physical networks or some area or concept of configuration. Elements may, for example, represent a single device such as a server, a range of IP addresses, or some configuration aid in the Management Center, such as a Category.
Page 318
See also Apply VPN Action (page 311). Engine The device that runs firewall, sensor, or analyzer software; a standard server or a StoneGate appliance. Represented by a Node in the Management Client.
Page 319
Gateway Profile An element that defines a set of VPN-related capabilities that a VPN Gateway supports. Gateway Settings An element that contains general settings for StoneGate firewall/VPN engines related to VPN performance. Gateway-to-Gateway VPN In StoneGate, a Virtual Private Network (VPN)
Page 320
Hardware A category of Tags for Situations. Meant for grouping Situations that detect known vulnerabilities in applications that run on a particular hardware platform. Hash Signature A cryptography-related concept that refers to a digital fingerprint associated with a given message and computed with one-way algorithms. Hash signatures are used to secure the integrity of encrypted data, ensuring that no tampering has taken place during transmission.
Page 321
Virtual Private Network (VPN) is being configured. Internal Network The networks and network resources that StoneGate is protecting. In StoneGate, there is no concept of internal and external networks in the system. Internet Key Exchange (IKE) A protocol defined by the...
Page 322
IP address of the component it licenses. If you need to change the IP address of the component, you must request an IP address change at the Stonesoft Licensing website. On engines, an alternative to a Management Bound License (page 324).
Page 323
Files you import to the system to tell the Management Server that the components you have installed have been legally purchased. You generate the Licenses at the Stonesoft Licensing website and import them to the Management Server using the Management Client. Lifetime...
Page 324
Malicious software designed to infiltrate or damage a computer system. Management Bound License License file for StoneGate engines that is based on information on the Management Server’s Proof of License (POL) code. An alternative to an IP Address Bound License (page 322).
Page 325
Single Firewall. Monitored Element A StoneGate server or engine component that is actively polled by the Management Server, so that administrators can keep track of whether it is working or not. All StoneGate system components are monitored by default. Monitoring Agent...
Page 326
"invalid" (non-routable) addresses to communicate on the Internet. Node Dedicated IP Address (NDI) (page 326). NetLink Element used for implementing routing of StoneGate’s Multi-Link features. NetLinks can represent any IP-based network links (such as ISP routers, xDSL, leased lines, dial-up modems). NetLinks are combined together into an Outbound Multi-link.
Page 327
Packet A segment of data sent across a network that includes a header with information necessary for the transmission, such as the source and destination IP addresses. Packet Dispatch Cluster Virtual IP Address (CVI) mode in which only one node in the cluster receives packets. This dispatcher node then forwards the packets to the correct node according to Load Balancing, as well as handles traffic as a normal node.
Page 328
Server. Probing Profile Settings that define how a Log Server monitors third-party components. Proof of License (POL) A code used for verifying the legitimate purchase of StoneGate software products. Used for generating License files at the Stonesoft website. Proof of Serial Number (POS) Identification code attached to StoneGate appliances.
Page 329
A string that describes a set of strings. Used in many text editors and utilities to search for text patterns and, for example, replace them with some other string. In StoneGate, regular expressions are used, for example, for defining patterns in traffic that you want a certain...
Page 330
Routing Table A database maintained on every router and gateway with information on paths to different networks. In StoneGate, the routing table is represented graphically in the Routing view. Rule An expression used to define the eventual outcome of packets arriving at the firewall, which match certain conditions (e.g., source and destination address, protocol, user).
Page 331
Sensor A StoneGate IPS component that captures all the traffic from a physical network link, inspects it according to its policy, and if installed inline, selects which connections are allowed to continue. Provides data for the Analyzer (see Analyzer (page 311)).
Page 332
The point at which the failure of a single device or component of a system will lead to either the failure of the entire system, or the inability to use services normally provided by that system. Redundant systems, using high availability technologies, eliminate single points of failure. Site A set of resources protected by StoneGate. Situation 1) An Element that identifies and describes detected events in the traffic or in the operation of the system.
Page 333
Secondary Management Server (page 331). Standby Mode An operating state of a StoneGate cluster that keeps one node online and the rest in standby, so that State Synchronization is done, but node does not process the traffic. If the online node is taken offline or fails, one of the standby nodes takes over the existing connections.
Page 334
Subtunnel The actual tunnels that are combined logically within a multi-route VPN tunnel in a StoneGate Multi-Link environment. They represent all possible routes that connect the end-points of the...
Page 335
Tester A tool that can automatically run tests on StoneGate engines to check system or network operation and take action based on the results of those tests. Timeline A tool in the...
Page 336
UTM device vary greatly from vendor to vendor. The StoneGate UTM comprises a firewall, deep packet inspection (IDS), and antivirus. Virtual Adapter A component of the StoneGate VPN Client, or a third party VPN client, that allows using a second, Virtual IP address Virtual Private Network (VPN) traffic.
Page 337
IP address belonging to a specific address range, while enabling it to retain its primary IP address for maintaining other connections. The Virtual IP address for StoneGate VPN Clients is always assigned by DHCP (Dynamic Host Configuration Protocol).
NDEX , 231 authentication methods for VPNs , 139 authentication servers , 83–98 access rules , 139 authentication services , 90 action in , 92 authentication in , 94–95 continue action in , 89 destination in , 199 bandwidth management , 93 for allowing system communications , 203...
Page 340
, 77 , 137 connectionless packet inspection external LDAP , 117–118 , 137 contact addresses classes and attributes in , 16 , 288 contact information schema files , 35 content inspection server, see CIS external network boundary , 222 content screening external security gateways see CIS , 170...
Page 341
, 44 gateway-to-gateway VPN, see VPN modem , 17 , 47–58 general firewall principles of firewall clusters , 230 , 41–46 GOST of single firewalls , 203 , 43, 53 guarantees for bandwidth physical , 204 speed setting for , 234 internal certificate authorities , 43, 55 internal DHCP server...
Page 342
, 95 in rules , 128 MSRPC , 23, 109–121 NAT (network address translation) , 128 NetBIOS , 117–118 contact addresses in , 128 oracle , 112 destination translation in , 128 remote shell , 111–112 dynamic source translation in , 129 services in firewall , 118...
Page 343
, 197 tester , 130 TFTP protocol agent , 215 SA (security association) , 92 time, in access rules , 226 satellite gateways , 56 timed synchronization settings , 151 security considerations for HTTPS inspection , 217 topologies for VPNs , 191–198 server pools , 28...
Page 344
, 230 GOST mode for , 215 IKE for , 234 internal certificate authorities for , 227 issues in , 229 logs for , 230 message digest algorithms for , 237 multi-link for , 229 NAT addresses, as endpoints for , 216 packet types in , 216...
Page 345
FI-00210 Helsinki Suite 900 Finland Atlanta, GA 30338 Tel. +358 9 476 711 Tel. +1 770 668 1125 Fax +358 9 4767 1349 Fax +1 770 668 1131 Copyright 2010 Stonesoft Corporation. All rights reserved. All specifications are subject to change.
Need help?
Do you have a question about the StoneGate and is the answer not in the manual?
Questions and answers