Table Of Contents
Advanced Policy Procedures
Policy Protection Role
Policy Structure and Operation
Policy Production Procedure
Policy Construction Phase
Policy Templates
TCP_NO_PROXY Policy Templates
Policy Template Parameters Configuration
Entering the Policy Template Configuration Command Level
Maximum Number of Services
Minimum Threshold
Disabling a Policy Template
Enabling a Policy Template
Viewing a Specific Policy Template
Configuring All Policy Template Parameters Simultaneously
Running the Policy Construction (Learning - Phase 1)
Ending the Policy Construction Phase
Accepting the Policy Construction Phase Results
Rejecting the Policy Construction Phase Results
Viewing Constructed Policies
Viewing specific Constructed Policies
Policy Operational Procedures
Concept Overview
Entering the Policy Path Command Group Level
Changing the Policy State
Adding a Service
Removing a Specific Service
Threshold Tuning Phase
Running the Threshold Tuning Phase
Ending the Threshold Tuning Phase
Accepting the Threshold Tuning Phase Results
Rejecting the Threshold Tuning Phase Results
Viewing the Policy Operational Parameters
Policy Operational Parameters
State
Threshold
Proxy-Threshold
Timeout
Action
Interactive-Status
Policy Administrative Procedures
Activating, inactivating and disabling a policy
Issuing the Show/ Show Details Commands
Viewing Zone Policies
Viewing Zone Policy Statistics
Viewing the Zone Policy Details
Viewing Zone Template Policies
Zone and Learning Phase Snapshot
Zone and Learning Parameter File Comparison
Copying Policies
Advanced Policy Procedures
This chapter supplies information about the Guard policies. This chapter consists of the following parts:
•
The role policies play in the Guard protection—This part details how policies integrate with the zone traffic protection scheme and interact with other protection components.
•
The procedure in which the Guard produces the policies —This part details the two policy production phases. Namely:
–
The Policy Construction Phase—The phase in which the Guard Policy Templates construct the policies. This phase consists of configuring the Maximum Number of Services and the Minimum Threshold parameters (see the "Maximum Number of Services" and the "Minimum Threshold" sections for further details).
–
The Threshold Tuning Phase—The phase in which the policies are tuned to fit the zone services traffic rates. This phase consists of the policy operational parameter configurations, namely, the procedures to configure the threshold, timeout, and action parameters.
•
TCP_NO_PROXY type zone policies.
•
Policy administrative procedures—This part details policy control procedures. These include procedures such as: enabling and disabling policies, issuing the show command, saving learning parameter snapshot, comparing between two learning-parameter files, and copying a service from zone to zone.
Policy Protection Role
The Guard as a zone traffic protector has to tightly attune to the zone traffic, monitor for suspicious indicators, and initialize a protective action. This is the role the Guard policies take. The Guard policies measure the particular traffic flows and once suspicious indicators in the form of threshold violations are sensed the policies assume an action. This action could range from merely notifying to directing the traffic to various Guard anti-spoofing or anti-zombie mechanisms.
Policy Structure and Operation
The Guard policy structure consists of sections. Each policy section has different role in relating to different traffic protection aspects. In the Guard Command Line Interface (CLI) environment the policy sections consist a policy path, which is also the policy name.
An example for a policy name is the following sample of a policy prompt line:
The Guard policies consist of the following sections:
•
Policy template—This policy section denotes which policy template produced the policy (see the "Policy Production Procedure" section for further details). The various policy templates produce policies that deal with the protection aspects the Guard requires for meeting the zone DDoS protection needs. The Guard, for example, requires monitoring the number of the connections requests sent to the zone. For that purpose, the concurrent_connections policy template would produce a group of policies that would relate (namely learn and obtain thresholds) to that specific traffic aspect. Policy templates are also zone type dependent.
For example, the Guard assigns an extra set of policy templates to produce policies to better adapt its protection to an Internet Relay Chat (TCP_NO_PROXY)-server-type zone (see the "TCP_NO_PROXY Policy Templates" section for further details). The Guard enables the user to manipulate the policy templates in that the user may control their policy production and functionality (see the "Maximum Number of Services", "Minimum Threshold", "Enabling a Policy Template", and "Disabling a Policy Template" sections for further details). The user also has the ability to control policy template output, namely the policy groups, by managing their ability to relate to their designated traffic, learn it and obtain thresholds (see the "Changing the Policy State" and "Threshold Tuning Phase" sections for further details). This ability enables the user to better tailor the Guard protection policies to its particular traffic characteristics and protection needs.
•
Service—This policy section denotes which zone port or protocol the protection policy would relate to. Protection policies have cross dependencies. For example, Policies relating to TCP services exclude the HTTP service ports the HTTP-related policies handle (see in the "Removing a Specific Service" section the details relating to the `any' parameter). The Guard enables the user not only to define the well-known ports or protocol numbers for the protection policies to relate to but also to configure specific ports and protocols for policy handling.
•
Protection module—This policy section denotes the traffic that underwent the anti-spoofing mechanisms of a specified protection module.
•
Packet type—This policy section denotes the packet types such as SYN (TCP-SYN) packets, and authenticated packets (namely packets that the Guard checked their connection performing a TCP handshake). This is one of the sensitive and selective protection abilities the Guard has. The Guard policies enable it to attune to packet types within a desired traffic flow for suspicious traffic indications.
•
Traffic characteristics—This policy section denotes the traffic characteristics for the policy to monitor. The policy may, for example, monitor traffic flowing to a zone for any source IP violating its threshold (see the "Viewing the Policy Operational Parameters" section for further details).
The Guard policy also has a set of parameters that define its operational aspects. These Operational Parameters define what the policy does to the traffic it learns and attunes to. The policy operational aspects are defined in terms of its triggering threshold violation, the action the policy assumes once such violation occurs, and the length of the time span for the policy action to last (see the "Policy Operational Parameters" section for further details).
The Guard defines its policy Threshold through traffic tuning. Setting it creates the starter for the policy to initialize its protection measures. Once the traffic the policy learned and tuned to have violated the policy Threshold the policy launches its action (see the "Action" section for further details). The Timeout parameter sets the minimum time span limit (that can also be indefinite) for the policy to apply its action (see the"Timeout" section for further details). Once the timeout expires, the Guard runs a checkout procedure in order to decide whether or not to deactivate a dynamic filter that was produced by the policy (see the "Advanced Dynamic Filters Configuration" section in Chapter 9, "Advanced Filter Procedures" for further details).
Policy Production Procedure
The policy construction procedure is the procedure in which the Guard takes the zone traffic and policy templates as its input and constructs the groups of policies as an output. The Guard then learns the traffic to tune those policy groups and define their policy thresholds. The policy production procedure consists, therefore, of the following phases:
•
Policy Construction Phase
•
Threshold Tuning Phase
Policy Construction Phase
In this phase the Guard, based on the zone traffic characteristics, discovers the main services used by the zone and produces the policies with the guiding rules of the Policy Templates.
Policy Templates
A Policy Template is a collection of policy constructing guiding rules and the output of each template is a group of policies. The Guard policy templates consist of the following:
•
http—This policy template produces a group of policies related to HTTP traffic flowing (by default) through port 80 (or other user-configured ports).
•
dns_tcp—This policy template produces a group of policies related to DNS-TCP protocol traffic.
•
dns_udp—This policy template produces a group of policies related to DNS-UDP protocol traffic.
•
fragments—This policy template produces a group of policies related to fragmented traffic.
•
ip_scan—This policy template produces a group of policies relating to IP scanning (A situation in which a Src IP tries to access many Dst IPs on the zone). This policy template is relevant when the zone is defined as a subnet.
By default this policy template is disabled. The default action for this policy template is notify.
Note
The policies created by the ip_scan policy template are resource consuming. Therefore, we recommend that the user use it attentively due to its potential performance penalty.
•
other_protocols—This policy template produces a group of policies relating to non TCP or UDP protocols.
•
port_scan—This policy template produces a group of policies relating to port scanning (A situation in which a Src IP tries to access many ports on the zone). By default, this policy template is disabled. The default action for this policy template is notify.
Note
The policies created by the port_scan policy template are resource consuming. Therefore, we recommend that the user use it attentively due to its potential performance penalty.
•
tcp_connections—This policy template produces a group of policies related to TCP connection characteristics.
•
tcp_not_auth—This policy template produces a group of policies related to TCP connections that haven't been authenticated by the Guard's anti-spoofing mechanisms.
•
tcp_ratio—This policy template produces sets of policies related to ratios between different types of TCP packets (e.g. SYN packets versus FIN/RST packets).
•
udp_services—This template produces a group of policies related to UDP services.
•
tcp_services—This policy template produces a group of policies related to TCP services on ports other than HTTP-related (i.e. ports 80, 8080, etc).
•
tcp_services_ns—This template produces a group of policies related to TCP services. By defaults the policy relates to IRC ports (666X), ssh and telnet. This policy template does not create policies with actions that direct traffic flows to the Strong protection module.
•
tcp_outgoing—This policy template produces sets of policies related to TCP connections initiated by the zone.
Note
The Guard first relates to indicators of TCP traffic on especially dedicated ports 6660 to 6670 and ports 21 to 23. Then:
•
If traffic is traced on those ports then the tcp_services_ns policy template produces its group of policies and the tcp_services policy template would relate to TCP services on other ports.
•
If no traffic is traced on the above-mentioned ports then the tcp_services policy template assumes its ordinary function. The tcp_services_ns policy template will not be operated.
•
The user may add services to this policy as to any other.
TCP_NO_PROXY Policy Templates
The Guard supplies the user with additional policy templates designed to tailor the Guard protection to zones for which no TCP proxy is to be used. This template may be used if the zone is moderated according to IP addresses such as an Internet Relay Chat (IRC) server-type zone.
These additional policy templates are the following:
•
tcp_connections_ns—This policy template produces a group of policies related to TCP connection characteristics. However, this policy template does not create policies with actions that direct traffic flows to the Strong protection module.
•
tcp_outgoing_ns—This policy template produces a group of policies related to TCP connections initiated by the zone. However, this policy template does not create policies with actions that direct traffic flows to the Strong protection module.
Policy Template Parameters Configuration
The user may configure the following policy template parameters:
•
Maximum Number of Services
•
Minimum Threshold
•
Policy Template state—Disabling a Policy Template and Enabling a Policy Template
During the Learning phases, the zone's traffic flows transparently through the Guard. Each active policy template produces a group of specified policies, according to the zone's traffic characteristics. The Guard enables the user to define the maximum number of policies the Guard will produce from a specified policy template. This is configured with the aid of the parameter: maximum number of services (see the "Maximum Number of Services"section for further details). The Guard ranks the services the policy template relates to by their level of traffic volume. The Guard will then pick up the services that have exceeded the defined minimum threshold (see the "Minimum Threshold" section for further details) with the highest traffic volume and create a policy for each one of them. Some of the policy templates will create an additional policy to handle all traffic flows for which a specific policy was not added. These policies will be added with a service of `any'.

Caution 
Configuring the policy templates assumes a user's thorough knowledge of the Guard application and zone traffic characteristics.
Note
These parameters are not configurable for all policy templates. The user may also enable and disable the policy template. See the "Enabling a Policy Template" and "Disabling a Policy Template" sections.
Entering the Policy Template Configuration Command Level
The user enters a Policy Template configuration command level to configure the policy template parameters.
To enter the Policy Template configuration command level perform the following:
1.
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy-template
<policy-template-name>
Where policy-template-name is the name of the desired policy template. The options are:
•
dns_tcp
•
dns_udp
•
fragments
•
http
•
ip_scan
•
other_protocols
•
port_scan
•
tcp_connections
•
tcp_not_auth
•
tcp_outgoing
•
tcp_ratio
•
tcp_services
•
tcp_services_ns
•
udp_services
See the "Policy Templates" section in this chapter for further details.
2.
Choose ENTER. The following prompt appears:
admin@GUARD-conf-zone-scannet# policy-template http
admin@GUARD-conf-zone-scannet-policy_template-http#
Maximum Number of Services
This parameter defines the maximum number of policies (each relating to a service) that will be produced from the specified policy template. The Guard ranks the services the policy template relates to by their level of traffic volume. The Guard will then pick up the services that have exceeded the defined minimum threshold (see the"Minimum Threshold" section for further details) with the highest traffic volume and create a policy for each one of them. An additional policy to handle all other traffic flows with the characteristics of the policy template may be added with a service of `any'.
This parameter may be defined only for policy templates that detect services, such as tcp_services. It cannot be configured for policy templates that relate to a specified service (such as dns_tcp that relates to service 53), or for policy templates that relate to a specified traffic characteristic (such as fragments).
Limiting the service number allows the user to better tailor the Guard protection policies to its preferred traffic flow requirements.
To configure the maximum number of services perform the following:
1.
From the Policy Template configuration command level type the following:
admin@GUARD-conf-zone-<zone-name>-policy_template-<policy-template
-name># max-services <max-services>
Where:
•
policy-template-name—The name of the desried policy template. See the "Policy Templates" section in this chapter for further details.
•
max-services—The maximum number of services
Note
It is recommended not exceed the maximum of ten services.
2.
Choose ENTER.
Minimum Threshold
This parameter defines the minimum traffic volume threshold for a service. Once the threshold is exceeded, the Guard produces policies that relate to the services' traffic according to the particular traffic flow that violated the threshold.
This parameter cannot be configured for policy templates that are essential for proper zone protection and therefore always produce a policy, such as fragments.
Setting the threshold enables the user to better adopt the Guard protection to the traffic volume of the user's zone services.
To configure the minimum threshold perform the following:
1.
From the Policy Template configuration command level type the following:
admin@GUARD-conf-zone-<zone-name>-policy_template-<policy-template
-name># min-threshold <min-threshold>
Where:
•
policy-template-name—The name of the desried policy template. See the "Policy Templates" section in this chapter for further details.
•
min-threshold—The number indicating the desired minimum threshold in the following units:
pps—Packets per second. When measuring the concurrent connection and syn/fin ratio the Threshold is in a number.
2.
Choose ENTER.
Disabling a Policy Template
This procedure prevents a policy template from producing policies once the Guard undergoes the Policy Construction phase.
Caution 
Removing a policy template results in the Guard's inability to protect the zone from traffic of the kind the policy template relates to. This may seriously compromise the Guard protection.
To disable a policy template perform the following:
1.
From the Policy Template configuration command level type the following:
admin@GUARD-conf-zone-<zone-name>-policy_template-<policy-template
-name># disable
2.
Choose ENTER.
Enabling a Policy Template
This procedure enables, a previously disabled, policy template to continue and produce policies once the Guard undergoes the Policy Construction phase.
To enable a policy template perform the following:
1.
From the Policy Template configuration command level type the following:
admin@GUARD-conf-zone-<zone-name>-policy_template-<policy-template
-name># enable
2.
Choose ENTER.
Viewing a Specific Policy Template
The user may wish to display the parameters of a specific Policy Template.
To view the parameters of a specific Policy Template perform the following:
1.
From the Policy Template configuration command level type the following:
admin@GUARD-conf-zone-<zone-name>-policy_template-<policy-template
-name># show
2.
Choose ENTER. The following sample screen is displayed:
admin@GUARD-conf-zone-scannet-policy_template-tcp_services#show
Policy Template: tcp_services
admin@GUARD-conf-zone-scannet-policy_template-tcp_services#
Configuring All Policy Template Parameters Simultaneously
To configure the policy template state, the maximum number of services and minimum threshold in a single command perform the following:
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy-template
<policy-template-name> <max-services> <min-threshold> {disabled |
enabled}
Where:
•
policy-template-name—The name of the desired policy template. See the "Policy Templates" section in this chapter for further details.
•
max-services—The maximum number of services
Note
It is recommended not exceed the maximum of ten services.
•
min-threshold—The number indicating the desired minimum threshold in the following units: pps - Packets per second. When measuring the concurrent connection and syn/fin ratio the Threshold is in a number.
•
disabled | enabled—Enable or disable the policy template (see the "Disabling a Policy Template" and "Enabling a Policy Template" sections in this chapter for further details).
Note
Type -1 in the max-services or min-threshold parameters to prevent the Guard from changing their current values.
Running the Policy Construction (Learning - Phase 1)
After configuring the policy template parameters the user runs the policy construction phase. The Guard, through its configured policy templates, now produces its protection policies.
To run the policy construction procedure perform the following:
1.
From the Global command group level type the following:
admin@GUARD# learning policy-construction <zone-name>
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># learning policy-construction
2.
Choose ENTER.
Note
We recommend letting the Policy Construction phase continue for at least two hours prior to proceeding.
Ending the Policy Construction Phase
Note
We recommend letting the Policy Construction phase continue for at least two hours prior to proceeding.
After a sufficient period of time, the user ends the Policy Construction phase.
The user may accept the Guard's suggested policies (see the "Accepting the Policy Construction Phase Results" section in this chapter for further details).
The user may decide to abort the first phase of the Learning process (see the "Rejecting the Policy Construction Phase Results" section in this chapter for further details). In this case, the Guard stops the process and erases all its learned data. As a result, the Guard falls back into its default settings (in the case of a new zone) or to the zone traffic configurations it had prior to the learning abortion.
The user may decide to view the learning process outcomes using the snapshot procedure prior to making a decision (see the "Zone and Learning Phase Snapshot" section in this chapter for further details).
Accepting the Policy Construction Phase Results
After a sufficient period of time (see the above note) the user ends the policy construction phase. The user may accept the results of the Construction Phase. The Guard then stops the Policy Construction Phase and adopts the results (policies). The newly learned policies take the place of the former policies.
Note
The user may wish to take a snapshot of the zone and current policy status. See the "Zone and Learning Phase Snapshot" section for further details.
To accept the policy Construction phase perform the following:
1.
From the Global command group level type the following:
admin@GUARD# learning <zone-name> accept
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># learning accept
2.
Choose ENTER.
Rejecting the Policy Construction Phase Results
The user may stop (reject) the policy construction phase. Rejecting the process causes the Guard to stop the Policy Construction phase and use polices and thresholds it had prior to the Learning phase initialization.
Note
The user may wish to take a snapshot of the zone and current policy status. See the "Zone and Learning Phase Snapshot" section for further details.
To reject the policy Construction phase perform the following:
1.
From the Global command group level type the following:
admin@GUARD# no learning <zone-name> reject
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># learning reject
2.
Choose ENTER.
Note
Aborting the Policy Construction Phase causes the Guard to fall back to its preconfigured policies either the default or the formerly configured policies.
Viewing Constructed Policies
The user may wish to display the zone's constructed policies to verify that these policies are well tailored to the zone traffic characteristics.
To view the zone's constructed policies perform the following:
1.
From the desired Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show policies
2.
Choose ENTER. The following partial sample screen appears:
admin@GUARD-conf-zone-scannet# show policies
|
|
|
|
|
|
|
|
dns_tcp/53/
analysis/pkts/
dst_ip
|
|
|
|
|
|
|
|
dns_tcp/53/
analysis/pkts/
global
|
|
|
|
|
|
|
|
http/80/strong
/syns/src_ip
|
|
|
|
|
|
|
|
http/80/strong
/syns/src_net
|
|
|
|
|
|
|
|
admin@GUARD-conf-zone-scannet#
The screen columns indicate the following:
•
Policy—Indicates the policy
•
State—Indicates the policy state (active, inactive or disabled)
•
IStatus—Indicates the policy interactive status (always-accept, always-ignore or interactive). See the"Interactive-Status" section in this chapter for further details.
•
Threshold—Indicates the policy threshold
•
Proxy—Indicates the proxy threshold defined for the policy
•
List—Indicates the number of specific IP thresholds defined for the policy
•
Action—Indicates the action the policy assumes once the threshold is violated
•
Timeout—The Timeout parameter sets the minimum time span limit (that can also be indefinite) for the policy to apply its action (see the "Timeout" section for further details). Once the timeout expires, the Guard runs a checkout procedure in order to decide whether or not to deactivate a dynamic filter that was produced by the policy (see the "Advanced Dynamic Filters Configuration" section in Chapter 9, "Advanced Filter Procedures" for further details).
The user should view the resulting screens with the following guiding question in mind: Are the Guard's produced policies related to the zone's major services?
The user may, as required, perform the procedures described in the "Policy Operational Procedures" section to better tailor the constructed policies to the zone traffic characteristics.
Viewing specific Constructed Policies
The user may wish to display the constructed policies from a specified policy template to verify that these policies are well tailored to the zone traffic characteristics.
To view the policies constructed from a specified policy template perform the following:
1.
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy <policy-template-name>
Where policy-template-name is the policy template name. See the "Policy Templates"section in this chapter for further details.
Note
Policies for which the Policy Template is disabled may not displayed in the policy list and therefore not configurable.
2.
Choose ENTER. The following prompt appears:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-template-name>#
3.
Type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-template-name>#
show details
Note
The user may issue the show details command at any stage of the policy prompt.
The screen columns display the policy's parameters as detailed in the "Viewing Constructed Policies" section.
Policy Operational Procedures
Concept Overview
The Guard policies have three possible states. These are the following:
•
Disable—The policy does not relate to the traffic flow and so no threshold is obtained. As a result, the policies will have to undergo a new learning threshold-tuning phase to ensure correct thresholds are applied for the policies.
Caution 
When a policy is disabled other policies may regard its targeted traffic as theirs. Therefore it is recommended to undergo a new learning threshold-tuning phase before the policies are applied in protect mode.
•
Inactivate—The policy relates to the traffic and obtains the threshold but launches no action when a threshold is violated. This procedure frees the user from the need to pass the policy through a new learning threshold-tuning phase. By default, all the Guard policies are activated.
•
Activate—The policy relates to the traffic and issues an action once the thresholds is violated.
Caution 
Unnecessarily inactivation or disabling may prevent the Guard policies from assuming their protective role and may compromise the zone protection.
Note
The user may disable a desired policy section before or after any of the Learning Phases.
The user may deactivate a desired policy section to prevent the policy from issuing actions the user regards as unwanted.
Note
Running the policy-construction phase after disabling a policy might result in the policy reconfiguration according to traffic flow. This could result in the policy re-activation.
The Activate, Inactivate, and Disable procedures may be applied at every section of the policy path. However, these procedures affect more policies when issued at the initial policy sections (e.g. Policy template or Port sections). The following figure describes an example of policy path sections:
The policy path consists of any of the following sections depending on the specific policy section:
<policy-template-name><service><protection
module><packet-type><traffic-characteristics>
Where:
•
policy-template-name—The policy template name. The options are:
–
dns_tcp
–
dns_udp
–
fragments
–
http
–
ip_scan
–
other_protocols
–
port_scan
–
tcp_connections
–
tcp_not_auth
–
tcp_outgoing
–
tcp_ratio
–
tcp_services
–
udp_services
See the "Policy Templates" section in this chapter for further details.
•
service—A well-known or defined port or protocol number. The user may use an "any" notation with the following in mind:
–
Regarding the tcp_services/udp_services that relate to specified ports (whether well known or user defined) - The "any" notation refers to all remaining ports unrelated by tcp_services/udp_services (i.e. in the no service tcp_services/any command, the any refers to ports yet unrelated by the tcp_services).
–
Regarding services that do not relate to specific ports (i.e. tcp_not_auth, fragments, etc.) - The "any" notation refers to a field wild card.
•
protection- module—The protection module name. The options are:
–
analysis—The protection module that lets the traffic flow without intervention
–
basic—The protection module that applies the Guard basic anti-spoofing mechanisms
–
strong—The protection module that applies the Guard strong anti-spoofing
•
packet-type—The packet type. The optional packet types are:
–
auth_pkts—Packets that underwent either TCP handshake or UDP authentication
–
auth_tcp_pkts—Packets that underwent TCP handshake
–
auth_udp_pkts—Packets that underwent UDP authentication
–
in_nodata_conns—zone incoming connections that have no data transfer on the connection (packets without a data payload)
–
in_conns—zone incoming connections.
–
in_pkts—zone incoming DNS query packets.
–
in_unauth_pkts—zone incoming unauthenticated DNS queries.
–
num_sources—Number of non-spoofed TCP source IPs, destined to the Zone.
–
out_pkts—zone incoming DNS reply packets.
–
reqs—Request packets with data payload
–
syns—Synchronization packets - TCP SYN flagged packets
–
syn_by_fin—SYN and FIN flagged packets. Verifies the ratio between the number of SYN flagged packets and the number of FIN flagged packets.
–
unauth_pkts—ackets that did not undergo TCP handshake
–
pkts—All packet types that do not fall under any other category in the same protection level
•
traffic-characteristics—The traffic characteristics. The following options designate policies that relate to the traffic aggregated according to the following characteristics:
–
dst_ip—Traffic destined to a zone IP address
–
dst_ip_ratio—The ratio of SYN and FIN flagged packets destined to a specific IP address
–
dst_port_ratio—The ratio of SYN and FIN flagged packets destined to a specific port
–
global—A summation of all traffic flow as defined by the other policy sections
–
src_ip—Traffic destined to the zone aggregated according to source IP address
–
src_net—Traffic destined to the zone aggregated according to source subnet IP address
–
dst_port—Traffic destined to a specific zone port
–
protocol—Traffic destined to the zone aggregated according to protocol
–
src_ip_many_dst_ips —his is the key used for ip scanning. Traffic from a single IP destined to many zone IP addresses
–
src_ip_many_ports—This is the key used for port scanning. Traffic from one IP destined to many zone ports
Entering the Policy Path Command Group Level
The user may enter a specific constructed policy or group of policies for configuration.
Note
The Guard enables the use of an asterisk (*) as a wildcard in each policy path section when configuring a group of policies, and when issuing the show policies details and the show policies statistics commands.
To enter the policy path command group level perform the following:
1.
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy <policy-path>
See the "Concept Overview" section in this chapter for further details.
2.
Choose ENTER.
Changing the Policy State
To change the policy state perform the following from the desired policy section:
1.
From the desired policy section prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path># state
<policy state>
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
policy state—The policy state. The policy state is one of the following:
disabled—The policy does not relate to the traffic flow and so no threshold is obtained.
inactive—The policy relates to the traffic and obtains the threshold but launches no action when a threshold is violated.
active—The policy relates to the traffic and issues an action once the thresholds is violated.
See "Concept Overview" in this section for further details.
Note
Typing "policy .." at a policy path prompt moves you up one level in the policy path hierarchy.
2.
Choose ENTER. The following sample screen displays an example:
admin@GUARD-conf-zone-scannet-policy-/tcp_services/any/basic/pkts/
dst_ip# state inactive
admin@GUARD-conf-zone-scannet-policy-/tcp_services/any/basic/pkts/
dst_ip#
Adding a Service
The Guard enables the user to manually add a service for a group of policies in addition to the services that were discovered in the policy construction phase described in the "Policy Construction Phase" section in this chapter. The new service is added to all policies that were created from the specified policy template. After adding the new service, the user may define the threshold manually, however, it is recommended to run the threshold-tuning phase (see the "Threshold Tuning Phase" section in this chapter for further details) to attune the policies to the zone's traffic.
Note
A new service may be added to the following policy templates:
•
tcp_services, udp_services, tcp_services_ns—The added service designates a port number.
•
other protocols, http—The added service designates a protocol number.
To add a service perform the following:
1.
From the Policy Template command group level type the following:
admin@GUARD-conf-zone-scannet-policy_template-<policy-template-nam
e># add-service <service-num>
Or alternatively:
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy-template
<policy-template-name> add-service <service-num>
Where:
•
policy-template-name—The policy template name. The options are:
tcp_services
tcp_services_ns
udp_services
other_protocols
See the note above for further details.
•
service-num—The desired service number:
tcp_services, udp_services, tcp_services_ns—The added service designates a port number.
other protocols—The added service designates a protocol number.
2.
Choose ENTER.
To add additional services repeat steps one and two.
Removing a Specific Service
The user may remove a specific service relating to a desired policy template.
Caution 
Removing a service prevents the Guard policies from relating to the removed traffic service and may compromise the zone protection.
To remove a specific policy perform the following:
1.
From the Policy Template command group level type the following:
admin@GUARD-conf-zone-scannet-policy-/<policy-template-name>#
remove-service <service-num>
Or alternatively:
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy-template
<policy-template-name> remove-service <service-num>
Where:
•
policy-template-name—The policy template name. The options are:
tcp_services
tcp_services_ns
udp_services
other_protocols
See the note above for further details.
•
service-num—The desired service number:
tcp_services, udp_services, tcp_services_ns—The added service designates a port number.
other protocols—The added service designates a protocol number.
2.
Choose ENTER.
To remove additional services, repeat steps one and two.
Threshold Tuning Phase
This is the stage in which the Guard further analyses the zone traffic and defines threshold for the policies constructed in the previous phase. The other policy operational parameters (the Timeout and Action) are configured by default. The Guard enables the user to configure its policy operational parameters.
Running the Threshold Tuning Phase
Note
We recommend running the threshold tuning phase for a period of a minimum 24 hours.
To run the Threshold Tuning phase perform the following:
1.
From the Global command group level type the following:
admin@GUARD# learning threshold-tuning <zone-name>
Or alternatively:
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># learning threshold-tuning
2.
Choose ENTER.
Ending the Threshold Tuning Phase
After a sufficient period of time, the user ends the Threshold Tuning phase.
The user may accept the Guard's suggested policy thresholds (see the "Accepting the Threshold Tuning Phase Results" section in this chapter for further details).
The user may decide to abort the second phase of the Learning process (see the "Rejecting the Threshold Tuning Phase Results" section in this chapter for further details). The Guard would stop the Threshold Tuning phase and adopt the Policy Construction Phase results and the former thresholds results the Guard has. This results in a situation in which newly constructed policies have thresholds that were obtained according to past traffic characteristics.
The user may decide to view the learning process outcomes using the snapshot procedure prior to making a decision (see the "Zone and Learning Phase Snapshot" section in this chapter for further details).
Accepting the Threshold Tuning Phase Results
After the threshold phase is run for a sufficient period of time the user may end it by accepting its learned threshold results. This causes the Guard to stop the Learning phase and adopt the results of its two phases.
Note
The user may wish to take a snapshot of the zone and current policy status. See the "Zone and Learning Phase Snapshot" section for further details.
To accept the Threshold Tuning phase perform the following:
1.
From the Global command group level type the following:
admin@GUARD# no learning <zone-name> accept
Or alternatively:
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># no learning accept
2.
Choose ENTER.
Rejecting the Threshold Tuning Phase Results
The user may reject the Threshold Tuning Phase results. If this is performed prior to accepting the Threshold tuning results the Guard would stop the Threshold Tuning phase and adopt the Policy Construction Phase and the former thresholds results the Guard has. This results in a situation in which newly constructed policies have thresholds that were obtained according to past traffic characteristics.
Note
The user may wish to take a snapshot of the zone and current policy status. See the "Zone and Learning Phase Snapshot" section for further details.
To reject the Threshold Tuning phase results perform the following:
1.
From the Global command group level type the following:
admin@GUARD# no learning <zone-name> reject
Or alternatively:
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># no learning reject
2.
Choose ENTER.
Viewing the Policy Operational Parameters
The user may wish to view specific policy operational parameters. Displaying these parameters helps the user to decide whether the policy operational parameters suit its zone traffic. The user may, when required, configure the policy operational parameters to better tailor the policy to its zone traffic requirements.
To view a policy operational parameters perform the following:
1.
From the desired policy traffic characteristics prompt, type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path># show
Where policy-path consists of any of the following sections depending on the specific policy section:
•
policy-template-name
•
service
•
protection module
•
packet-type
•
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
2.
Choose ENTER. The following, sample, screen appears:
admin@GUARD-conf-zone-scannet-policy-/http/80/strong/syns/global#
show
Policy: http/80/strong/syns/global
Interactive-Status: always-accept
admin@GUARD-conf-zone-scannet-policy-/http/80/strong/syns/global#
Policy Operational Parameters
The Guard policies also consist of operational parameters. These are:
•
State
•
Threshold (including a Specific IP Threshold Configuration)
•
Proxy-Threshold
•
Timeout
•
Action
•
Interactive-Status
State
The user may set the policy operation state. See the "Changing the Policy State" section for further details.
Threshold
This parameter defies the threshold traffic rate for a specific policy. Once violated, the policy assumes an action to protect the zone. The threshold is set by default to a value appropriate for on-demand protection. It is adjusted by the threshold-tuning phase in the learning procedure, and can be manually configured by the user.
To configure the Threshold operational parameter perform the following:
1.
From the desired policy traffic characteristics prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-/<policy-path># threshold
<threshold>
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
threshold—The threshold traffic rate for a specific policy. Once violated, the policy assumes an action to protect the zone.
The threshold may be measured in packets per second (pps) for policies such as http.
The threshold may be measured in number of connections for policies such as tcp_connections.
The threshold may be measured in the ratio number for policies such as tcp_ratio.
2.
Type in the desired threshold and choose ENTER.
3.
Perform the procedure in the "Viewing the Policy Operational Parameters" section in this chapter to view the newly configured threshold.
Increasing a Threshold by a Factor
The Guard enables the user to increase a policy or a group of policies (see the note in the "Entering the Policy Template Configuration Command Level" section) threshold by a user-configurable factor.
To increase a policy, or policies, threshold by a factor perform the following:
1.
From the Zone command level type the following:
admin@GUARD-conf-zone-scannet# policy <policy-path> thresh-mult
<threshold-multiply-factor>
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
threshold-multiply-factor—An integer threshold-increasing factor.
2.
Choose ENTER. The following, sample, lines appear:
multiply threshold of tcp_ratio/any/basic/syn_by_fin/dst_ip_ratio
by 2:
1 policy thresholds modified.
admin@GUARD-conf-zone-scannet#
Specific IP Threshold Configuration
In case of known high-volume traffic IP source, the user may configure a particular threshold to apply to that IP source address.
In case of a non-homogenous zone (i.e. a zone that has more than has more than a single IP defined) for which there is known high-volume traffic only to part of the zone, the user may configure a particular threshold to apply to that IP destination address.
The configured threshold applies in the following policies:
Note
The configured threshold applies in the following policies:
•
Specific IP threshold can be configured for policies with traffic characteristics of source IP and subnet with the action of drop and a policy with traffic characteristic of destination IP with the actions of to-user, strong, notify, and drop (i.e. Policies of key src_ip, dst_ip and src_net).
•
In all other cases the policies relate to their attuned thresholds.
To configure a specific IP threshold perform the following:
1.
From the desired policy traffic characteristics prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path>#
threshold-list <ip> <threshold> [<ip> <threshold> ...]
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># policy <policy-path>
threshold-list <ip> <threshold> [<ip> <threshold> ...]
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
ip—The specific IP address
•
threshold—The threshold traffic rate in pps - Packets per second. When measuring the concurrent connection and syn_by_fin ratio the Threshold is in a number.
2.
Choose ENTER. The following, sample, screen appears:
admin@GUARD-conf-zone-scannet-policy-/http/80/strong/syns/src_ip#
threshold-list 10.10.10.2 500 10.10.15.2 500
admin@GUARD-conf-zone-scannet-policy-/http/80/strong/syns/src_ip#
Proxy-Threshold
This parameter defines the traffic rate for clients that connect to the zone in HTTP via proxies. It enables the Guard and the user to better tailor the policy reaction to traffic volumes coming from different sources.
Note
proxy-threshold is available only for policies for which it was discovered during the learning phase.
To configure the Proxy-threshold operational parameter perform the following:
1.
From the desired policy traffic characteristics prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path>#
proxy-threshold <proxy-threshold>
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
proxy-threshold—The proxy-threshold traffic rate in packets per second (pps). When measuring the concurrent connection and syn/fin ratio the Threshold is in a number.
•
Choose ENTER.
Timeout
This parameter defines the minimum time span for the policy to apply its action. Once the timeout expires, the Guard runs a checkout procedure in order to decide whether or not to deactivate a dynamic filter that was produced by the policy (see the "Advanced Dynamic Filters Configuration" section in Chapter 9, "Advanced Filter Procedures" for further details).
To configure the Timeout operational parameter perform the following:
1.
From the desired policy traffic characteristics prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path># timeout
{forever|<timeout>}
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
timeout—The time out span measured in seconds.
•
forever—Indefinite time span
•
timeout—A limited time span (an integer) defined in seconds.
2.
Choose ENTER.
3.
Perform the procedure in the "Viewing the Policy Operational Parameters" section in this chapter to view the newly configured threshold.
Note
When typing the policy path from the zone command level command the timeout parameter changes to set-timeout.
Action
This parameter defines the action type the policy assumes once its threshold is violated.
To configure the Action operational parameter perform the following:
1.
From the desired policy traffic characteristics prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path># action
{block-unauth| strong| to-user-filters| drop| redirect/zombie |
notify}
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
action—The action a policy assumes as a result of a threshold violation.
•
block-unauth—The policy adds a filter that blocks traffic that was not authenticated by the anti-spoofing mechanism.
•
strong—The policy adds a filter directing the traffic to the Strong protection module mechanisms.
•
to-user-filters—The policy adds a filter directing the traffic to the user filters.
•
drop—The policy adds a filter directing the traffic to the Drop protection module to be dropped.
•
redirect/zombie—The policy adds a filter that enhances authentication for all User filters with an action of redirect.
•
notify—The policy notifies the user of the threshold violation.
2.
Choose ENTER.
Note
When typing the policy path from the zone command level command the action parameter changes to set-action.
Interactive-Status
This parameter defines the interactive-status the pending Dynamic filters, created by the policy, assume. Interactive-Status is applicable only for zones in interactive mode.
See Chapter 11, "Interactive Recommendations Mode" for further details.
To configure the Interactive-status operational parameter perform the following
1.
From the desired policy traffic characteristics prompt type the following:
admin@GUARD-conf-zone-<zone-name>-policy-<policy-path>#
interactive-status {always-ignore|always-accept|interactive}
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
interactive-status—The policy's interactive status.
•
always-accept—The user decides to accept the specific Dynamic filters the policy will produce. The user decision applies automatically whenever the recommendation policy produces new recommendations. Their pending filters will automatically turn to dynamic.
Note
The Guard doesn't display the always-accept recommendations.
•
always-ignore—The user decides to ignore the specific Dynamic filters created by the policy. No dynamic filter or filters will be produced by the policy. The user decision automatically applies to all recommendations produced by the recommendation's policy.
Note
The Guard doesn't display the always-ignore recommendations.
•
interactive—The user will decide to accept or ignore the specific Dynamic filters the policy will produce in an interactive manners. The Dynamic filters the policy produces will be displayed as part of the recommendations.
2.
Choose ENTER.
Policy Administrative Procedures
The user may perform procedures relating to policy operations and policy configuration data. These procedures are the following:
•
Activating, inactivating and disabling a policy
•
Issuing the Show/ Show Details Commands
•
Zone and Learning Phase Snapshot: Saving a current Guard learning parameters snapshot
•
Zone and Learning Parameter File Comparison: Comparing between two learning-parameter files
•
Copying Policies: Copying a desired service from zone to zone
Activating, inactivating and disabling a policy
The user may activate, inactivate or disable a policy. See the "Changing the Policy State" section for further details.
Issuing the Show/ Show Details Commands
The user may issue the show and show details commands at any section of the policy prompt line. However, this command yields two types of information:
•
The show commands yields information relating to policy state, Action, and operational parameters when issued at the Traffic Characteristics policy prompt line section. As the following screen sample displays:
admin@GUARD-conf-zone-scannet-policy-/http/80/strong/http_reqs/glo
bal#show
Policy: http/80/strong/http_reqs/global
Interactive-Status: always-accept
•
The show commands yields policy status when issued at the rest of the policy prompt line sections. As the following screen sample displays:
admin@GUARD-conf-zone-scannet-policy-/http/80/strong#show
admin@GUARD-conf-zone-scannet-policy-/http/80/strong#
Viewing Zone Policies
The user may view a specific zone's policy list.
See the "Viewing Constructed Policies" section for further details.
Viewing Zone Policy Statistics
The user may view a specific zone or a group of policies' statistics. This enables the user to view the rate of the traffic flowing through each policy.
To view a list of all of a zone policies' statistics perform the following:
1.
From the desired Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show policies statistics
2.
Choose ENTER. The following partial sample screen appears:
admin@GUARD-conf-zone-scannet#show policies statistics
192.168.100.34 1.29 tcp_not_auth/any/strong/pkts/dst_ip
N/A 1.29 tcp_not_auth/any/strong/pkts/global
192.168.100.0 0.08 http/80/basic/syns/src_net
192.168.100.44 0.03 http/80/basic/syns/src_ip
192.168.100.46 0.02 http/80/basic/syns/src_ip
192.168.100.35 1.91 tcp_connections/any/strong/in_conns/src_ip
N/A 1.91 tcp_connections/any/strong/in_conns/global
192.168.100.45 1.67 tcp_connections/any/strong/in_conns/src_ip
192.168.100.42 1.38 tcp_connections/any/strong/in_conns/src_ip
admin@GUARD-conf-zone-scannet#
The screen columns indicate the following:
•
Key—Indicates the key which designates policies that relate to the traffic aggregated according to a specified parameter. For example, in the udp_services/any/analysis/pkts/src_ip policy, the key is src_ip. The specified key in the example above is 8.202.131.235.
•
Rate—Indicates the rate of the traffic flowing through the policy measured in packets per second (pps).
Note
The rate is calculated based on traffic samples.
•
Policy—Indicates the policy.
•
Connections—Indicates the number of concurrent connections. This information is available for the policies: tcp_connections and for the following packets types:
in_nodata_conns for the analysis protection module
in_conns for the strong protection module
•
Ratio—Indicates the ratio between the number of SYN flagged packets and the number of FIN flagged packets. This information is available only for the policies: syn_by_fin.
Note
The Guard enables the use of an asterisk (*) as a wildcard in each policy path section.
To view a specific policy group statistics perform the following:
1.
From the desired Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show policies statistics
<policy-path> <num-entries>
Where:
•
policy-path consists of any of the following sections depending on the specific policy section:
policy-template-name
service
protection module
packet-type
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
•
num-entries—Lists the desired number of policies sorted by their rate in a descending order.
2.
Choose ENTER. The following, sample, screen appears:
admin@GUARD-conf-zone-scannet#show policies statistics http/80/
*/syns/dst_ip 3
192.168.131.4 133.58 http/80/analysis/syns/dst_ip
192.168.97.34 37.42 http/80/basic/syns/dst_ip
192.168.132.65 1.15 http/80/strong/syns/dst_ip
Viewing the Zone Policy Details
The user may view, in detail, a specific zone policy or a group of policies' data.
Note
The Guard enables the use of an asterisk (*) as a wildcard in each policy path section.
To display a detailed view of a specific zone policy or a group of policies' data perform the following:
1.
From the desired Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># show policies details <policy
path>
Where policy-path consists of any of the following sections depending on the specific policy section:
•
policy-template-name
•
service
•
protection module
•
packet-type
•
traffic-characteristics
See the "Concept Overview" section in this chapter for further details.
2.
Choose ENTER. The following, sample, screen appears:
|
|
|
|
|
|
|
|
tcp_outgoing/
any/analysis/
reqs/src_ip
|
|
|
|
|
|
|
|
tcp_services/
any/analysis/
reqs/src_ip
|
|
|
|
|
|
|
|
The table columns are the following:
•
Policy—This column denotes the policy name.
•
State—This column denotes the policy state (act-active, en-enable, dis-disable). See the "Disabling a Policy Template" and "Enabling a Policy Template" sections in this chapter for further details.
•
Istatus—This column denotes the policy interactive status (a-accept-always accept, a-ignore-always ignore, interactive). See the "Deciding on a Specific Recommendation" section in Chapter 11, "Interactive Recommendations Mode" for further details.
•
Threshold—This column indicates the policy threshold. See the "Threshold" section in this chapter.
•
Proxy—This column indicates the policy proxy threshold. See the "Threshold" section in this chapter.
•
List—This column indicates the number of IP thresholds defined for the policy. See the "Specific IP Threshold Configuration" section in this chapter.
•
Action—This column denotes the policy action. See the "Action" section in this chapter.
•
Timeout—This column denotes the policy timeout.
Viewing Zone Template Policies
The user may view a specific zone's template policies. This list consists of all the policies a zone template includes by default.
To view the zone template policies perform the following:
1.
From the Global command group level type the following:
admin@GUARD# show templates <template-name> policies
Where template-name is the desired zone template name. The options are:
•
DEFUALT—The Guard default zone template.
•
TCP_NO_PROXY—A template designed for a zone for which no TCP proxy is to be used, such as an Internet Relay Chat server (IRC).
•
LINK_128K—A template designed for link detection.
•
LINK_1M—A template designed for link detection.
•
LINK_4M—A template designed for link detection.
•
LINK_512K—A template designed for link detection.
2.
Choose ENTER. The following partial sample screen appears:
admin@GUARD#show templates DEFAULT policies
|
|
|
|
|
|
|
|
dns_tcp/53/
analysis/pkts/
dst_ip
|
|
|
|
|
|
|
|
dns_tcp/53/
analysis/pkts/
global
|
|
|
|
|
|
|
|
dns_tcp/53/
analysis/pkts/
src_ip
|
|
|
|
|
|
|
|
... ... ...
dns_tcp/53/
analysis/pkts/
src_net
|
|
|
|
|
|
|
|
See the "Viewing Zone Policies" section in this chapter for further details on the screen columns.
Zone and Learning Phase Snapshot
The user is able to save a snapshot of the learning parameters (services, thresholds and other policy related data) at any time of the Learning phase and later review it. The file containing the snapshot learning phase parameters together with the zone configuration parameters is saved under a user defined zone name. Thus a new zone would be created bearing the configurations and policy parameters (number of services, thresholds, action, timeout, etc.) of the zone at snapshot time.
Note
The Guard continues its Learning phases as the snapshot is taken.
To save a Learning phase snapshot perform the following:
1.
From the Global command group level type the following:
admin@GUARD# snapshot <zone-name> <new-zone-name>
Where:
•
zone-name—The name of the zone whose learning parameters are saved.
•
new-zone-name—The name of the saved Learning and zone parameters. The name should be of a new zone name.
2.
Choose ENTER. The following screen displays a case in which a zone learning parameter file is saved under the same zone name:
admin@GUARD# snapshot scannet scannet.tmp
Note
The snapshot command is applicable while the zone is in Learning only.
Note
The Snapshot creates a new zone. After verifying the snapshot parameters, or comparing two snapshots, the user may choose to delete the snapshot.
Alternatively, the user may choose to keep the snapshot and delete the originating zone.
Zone and Learning Parameter File Comparison
The user is able to compare between the snapshot Learning parameters and the zone Learning parameters. The comparison is held to trace differences in policies, services, and thresholds. The user is able to define the comparator's differing sensitivity.
To compare between two Learning parameter files perform the following:
1.
From the Global or Configuration command group levels type the following:
admin@GUARD# diff <zone-name> <zone-name> [<percent>]
Where:
•
zone-name—The names of the zone whose learning parameters are compared.
•
percent—(Optional) The traced differing percentage. The Guard will trace any parameters that differ above the defined percentage.
Note
The default is 100% if no percentage is defined. The Guard then traces every difference in compared parameters.
2.
Choose ENTER. The following screen displays a partial sample:
admin@GUARD#diff scannet scannet1 80
No services that are only in scannet1.
Services only in scannet:
No policies where action or state differs.
Policies where thresholds differ by more than 80 percent:
|
|
|
|
|
dns_tcp/53/analysis/pkts/dst_ip
|
|
|
dns_tcp/53/analysis/pkts/global
|
|
|
dns_tcp/53/analysis/pkts/src_ip
|
Copying Policies
In this procedure the user is able to copy policy configuration from a source zone to the current zone. The user is able to copy the data relevant to the produced policies on a desired port, or all policies. The data includes the policy's operational parameters (threshold, action, interactive-status and timeout).
Note
This command is useful for zones with similar traffic patterns to share the same policies without the need to apply the learning phases to the destination zone.
To copy a service from a source zone perform the following:
1.
From the Zone command group level type the following:
admin@GUARD-conf-zone-<zone-name># copy-services <src-zone-name>
[<service-path>]
Where:
•
src-zone-name—The names of the zone whose service data will be copied.
•
zone-name—The zone name. This zone will be configured with the coppied policies.
•
service-path—The desired service to be copied denoted by the following options:
policy-template service-num—Copying applies to the policies relating to a specified port.
policy-template—Copying applies to the policies relating to the policy template.
Note
If no service path is specified, all policy templates and ports are copied.
2.
Choose ENTER. The following prompt appears:
admin@GUARD-conf-zone-scannet#copy-services webnet
tcp_connections/
admin@GUARD-conf-zone-scannet#