Optionally, you can set a specific time period when a rule is applied using the Time cell. The validity of the rule can be set by month, day of the week, and time of day. For example, you might have certain rules that allow access only during business hours on weekdays. If you leave the Time cell empty, the rule is always valid.
Task 7: Restrict the Rule Match Based on Source VPN
Optionally, you can match the rule based on whether the traffic is coming from a VPN. You can define that the rule matches only non-VPN traffic, or only traffic from a certain VPN. For more information, see Overview to VPNs (page 235).
Table 9.4 Log Levels in Access Rules
Log Level Explanation
Alert An alert entry is generated.
Stored A log entry is generated and stored on the Log Server.
Essential When the Log Server is unavailable, log entries are temporarily stored on the Firewall engine. When the Firewall engine is running out of space to store the log entries, it begins discarding log data in order of importance.
Transient A log entry is only available for immediate display in the Logs view and is not stored.
None The rule does not produce any log entries.
Note – The times are entered in Coordinated Universal Time (UTC), and you must adjust the times you enter to make them correspond to the firewall’s local time zone. Also consider that UTC time does not adjust to daylight saving time (summer time).
Using Access Rules
The general configuration of Access rules is explained above. The sections below provide further information on configuring Access rules:
•Allowing System Communications (page 95)
•Configuring Default Settings for Several Rules (page 95)
•Using Aliases in Access Rules (page 97)
•Creating User-Specific Access Rules (page 97)
•Using Domain Names in Access Rules (page 98)
•Interface Matching in Access Rules (page 98)
For general information on using rules, see Using Policy Elements and Rules (page 79).
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.
For example, in a configuration where you have a firewall and a Log Server at a remote site that are managed by a Management Server behind a firewall at a central site, you must create rules in the Firewall Policy at the central site to allow:
•Management and monitoring connections to/from the remote firewall.
•Monitoring and log browsing connections from the central site to the remote Log Server.
•Any remote-site Management Client connections to the Management Server at the central site.
If NAT is applied to the connections, Access rules alone are not enough. You must also create Location elements and add Contact Addresses for the elements to define which translated addresses are necessary for making contact (see NAT and System Communications (page 120)).
There are predefined Service elements in the system for all system communications. You can use these to create Access rules. See Default Communication Ports (page 285) for more information on system communications.
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. This matching rule uses the defaults set in the Continue rule unless the rule specifically overrides the defaults with different settings. This way, you do not have to define the settings for each rule separately. You can use Continue rules to set default settings for a general type of traffic and
The options that can be set using Continue rules in Access rules include:
•The Connection Tracking option (default is on), including its sub-options:
•The Idle Time-out (overrides also the global defaults set in the Firewall element’s properties).
•The concurrent connection limits set per single source and/or destination IP address.
•The logging options (default is Stored).
•The Protocol inside the Service (used to apply a Protocol to rules with ANY as their Service, see Using Continue Rules to set the Protocol (page 97)).
•The QoS Class (default is that no specific QoS Class is assigned).
Continue rules are defined the same way as other rules. However, you must keep in mind that when any of the options listed above is set in the Continue rule, many or even all rules below may be affected. The Continue rule options are used by the rules below, provided that the Source, Destination, Service, and the optional Source VPN definition match the same
connection as the Continue rule. Continue rules are inherited from Template Policies into lower-level templates and policies like any other rules.
Continue rules behave in the same way as any other rules. A Continue rule can be overridden by some subsequent Continue rule that has an identical scope (Source, Destination, etc.), or partially overridden by a Continue rule that partially overlaps with the previous Continue rule.
When you define Continue rules with different matching criteria, you can have several Continue rules one after another without them interfering with each other in any way at all.
Sub-Policies may require special attention with Continue rules: the Sub-Policies may have different options when you insert them into different policies if the Sub-Policy rules do not override the options set by preceding Continue rules. Also, when a Sub-Policy contains a Continue rule, the options are then used for further matching in the higher-level policy (if the processing returns to the higher-level policy).
Using Continue Rules to Set Logging Options
One common use for the Continue action is to set the default log level for all subsequent rules.
Instead of setting the logging option for all rules individually, you can set a Continue rule in a template or in a policy to set the default log level. The logging level for any subsequent matching rules can be left undefined, yet they trigger logging as defined in the Continue rule.
Illustration 9.4 Setting the Default Log Level
In Illustration 9.4, 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. Individual rules can still override this option with specific log levels, such as Essential or Stored.
There is also a default logging setting that is used if logging is not defined for a rule and there is no prior Continue rule that would determine its logging mode: an Access rule will generate a Stored log entry in that case.
Using Continue Rules to set the Protocol
The default Protocol can be set using the Continue action. This way, the correct Protocol is also used for traffic that is allowed by rules that are set to match any Service (this may be even be mandatory, for example, if you want to allow certain protocols that allocate ports dynamically).
The Default template includes one Continue rule that defines that Protocols of the type Agent are used for the Service Group Default Services with Agents.
Illustration 9.5 Default Template Protocol Agent Rule
If you want to set a Protocol for more types of protocols or override the Default rule shown in Illustration 9.5 for some or all connections, place one or more Continue rules at the top or some other suitable place in your own template or policy. The Source and Destination can be some specific addresses if you want to limit the scope of your Continue rules.
For more information on using Protocols of the type Agent in rules, see Protocol Agents (page 127).
Using Aliases in Access Rules
Aliases are one of the most useful tools for reducing the complexity of a policy. With Aliases, you can avoid creating multiple, near-duplicate rule sets when you have several firewalls. The Alias element is used like any other network element. However, the IP addresses that the Alias represents depends on the Firewall where the rules are installed. The IP address to firewall mapping is defined in the Alias element.
For example, in a company that has offices in several different locations, each office can have its own Web server. The Web server rules could be put in a single Sub-Policy, but each location’s Web server has a different IP address. Normal rules would require allowing access to all IP addresses on all firewalls, which is not only unnecessary, but can also be considered a security risk. Using Aliases, the company can create a single set of rules that are still valid when applied to multiple firewalls, but which do not allow access to IP addresses that are not in use on a particular firewall.
In this way, Aliases simplify policies without reducing security.
Creating User-Specific Access Rules
The optional User Agent can be installed on a Windows Server that communicates with an Active Directory Domain Controller to associate users in an integrated Active Directory database with IP addresses. For more information, see User Agents for Active Directory (page 183). This makes it possible to use User and User Group elements as the source or destination of a rule to create user-specific rules without requiring user authentication.
Information about Users’ IP addresses is cleared from the firewall’s cache if the firewall becomes unable to contact the User Agent. This can prevent rules that block connections from matching. For this reason, it is recommended to use Users and User Groups only in rules that allow a connection.
Additionally, Users may be incorrectly removed from the list of IP addresses if the User’s workstation does not respond to an ICMP echo (ping) request from the User Agent. Workstation monitoring can optionally be disabled in the Windows registry to prevent this. See the User Agent Release Notes for more information.
User-specific rules do not replace user authentication; they are a tool to simplify the
configuration of access control, and improve the end-user experience by allowing transparent access to services. They are intended to be used for trusted users in a trusted environment where strong authentication is not required. User-specific rules can be used together with user authentication rules to allow some user groups to access a service, while otherwise requiring authentication for the same service.
Using Domain Names in Access Rules
You can use Domain Name elements in Access rules to represent an Internet domain that may be associated with multiple IP addresses. The firewall automatically resolves the domain names to IP addresses.
Interface Matching in Access Rules
Zone elements are interface references that can combine several network interfaces of a engine into one logical entity. Using Zones in the Source or Destination cells allows you to restrict traffic according to which firewall interface(s) the traffic is travelling through. This can be useful, for example, when a certain type of traffic is only considered valid it when it travels through a specific interface, but basic Anti-Spoofing would have allowed the traffic on any interface.
Examples of Access Rules
The examples in this section illustrate some common uses for Access rules and general steps on how each scenario is configured.
Example of Rule Order
Company A has an office network, a DMZ for WWW servers, and a second DMZ for an FTP server. At this point, the administrators only need to add rules for the DMZ traffic.
Illustration 9.6 Company A’s Communications of Special Interest
The WWW servers must be accessible to anyone from both internal and external networks. HTTP traffic will be inspected against the Inspection rules, excluding the administrators’ own PCs (on the right in the illustration), since they often test the servers for vulnerabilities. The FTP server is accessible to all users in the general office network, but only to certain external users (on the left in the illustration) that authenticate using an external authentication server.
The administrators:
1. Create Host elements for the WWW servers, the FTP server, and the administrators’ PCs.
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.
Administrators Internet
FTP Server
WWW Servers Authenticating
Users
Internal Network
6. Add IPv4 Access rules with the Allow action for access to the DMZs:
•As seen in the rule table, there are two rules for traffic to both the WWW servers and the FTP server.
•The rules are arranged so that the more specific rules are above the more general rules.
For example, the rule allowing administrators to connect to the WWW servers without checking against the Inspection rules is above the more general rule that allows any connection to the servers as subject to the Inspection rules.
•If the first two rules were in the opposite order, the rule specific to administrators would never match, as the rule with the source as ANY would be applied first, the connection would be allowed according to that general rule, and the firewall would stop checking the rule table.
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. The administrators want to follow how much traffic is allowed using the highest priority, so they also want to make sure that this traffic is logged with the accounting option turned on. They decide that the lower priorities of traffic need not be permanently logged at this point, so the administrators:
1. Configure the QoS features.
2. Create elements for all high-priority hosts.
Table 9.5 Access Rules for the DMZ
Source Destination Service Authentication Action
“Administrator
PCs” Group “WWW Servers”
Group “HTTP” Service Allow (Deep
Inspection Off)
ANY “WWW Servers”
Group “HTTP” Service Allow (Deep
Inspection Off) Network element
for Office Network “FTP Server”
Host “FTP” Service Allow (Deep
Inspection Off)
3. Add the following Access rules to the top of their policy:
•After adding these rules, individual rules can override the settings as needed, but most of the existing rules governing access from internal networks to the Internet now use the QoS Class and Logging options as set in these rules.
4. Transfer the policy to the firewall.
Example of User-Specific Rules
Company C has an existing Microsoft Active Directory server that it uses for user accounts in its Windows domain. Users are divided into groups according to the department they work in. The administrators have already integrated the Active Directory user database with StoneGate to be able to view and manage Users in the Management Client.
There is already an Access rule that blocks access to a popular video sharing site. However, the marketing team needs to be able to publish videos for its new marketing campaign on the site.
The administrators want to allow users in the marketing group to access the site, but do not want to require user authentication in StoneGate.
Because the video sharing site has multiple servers with different IP addresses, the
administrators decide to use a Domain Name element to dynamically resolve the IP addresses of servers in the video sharing site’s Internet Domain.
The administrators:
1. Install the User Agent on a Windows server that communicates with the Active Directory Domain Controller.
2. Create a User Agent element and select it in the firewall’s properties.
3. Add the following Access rule before the rule that blocks access to the video sharing site:
Table 9.6 Continue Rules for Logging and QoS Class
Source Destination Service Action Logging QoS Class
Important Hosts ANY ANY Continue Stored with
accounting High priority Network element
for Important Network
ANY ANY Continue Transient Medium priority
All other Hosts ANY ANY Continue Transient Low priority
Table 9.7 User-Specific Access Rule
Source Destination Service Action
Marketing user group Domain Name element that represents the
video sharing site HTTP Allow
C HA PT E R 10
I NSPECTION R 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 104)
Configuration of Inspection Rules (page 105)
Using Inspection Rules (page 110)
Example of Inspection Rules (page 111)
Overview to Inspection Rules
Inspection rules define how the main traffic analysis is done for traffic that has been allowed and selected for inspection in the Access rules. The Inspection rules are stored in policy elements, which are discussed in Firewall Policies (page 71).
Inspection rules examine the entire contents of the packets throughout whole connections to see if the data being transferred contains a pattern of interest. The main source of these patterns are the dynamic update packages that Stonesoft releases, but you can also define new patterns as Situation elements, which are discussed in Situations (page 163). Using the inspection capabilities on the firewall requires enough hardware resources available to support the feature, as the inspection process is memory-intensive.
There are three general types of cases for using Inspection rules:
•You can detect attempts to exploit known vulnerabilities in your systems and prevent such attempts from succeeding if the system is not patched against it.
•You can monitor traffic that does not cause alarm on the surface, but when examined for certain patterns, may turn out to conceal actual threats. For example, you can detect if a series of occasional service requests are actually someone secretly scanning the network structure or if a spike in traffic is a denial-of-service attack under way.
•You can also detect other sequences in traffic, such as the use of certain applications or even access to a particular file.
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.
Based on the detection results, the Inspection rules provide several different ways to react when some traffic is found to match a pattern of interest:
•Stop the traffic.
•Reset the connection.
•Allow the traffic.
Regardless of which of the above actions is taken, you can also create:
•A log entry with or without recording an excerpt of the detected traffic.
•A log entry with or without recording an excerpt of the detected traffic.