Table Of Contents

Guard Configuration

Guard Interface Configuration

Guard Interface Procedures

Configuring a Physical Interface

Assigning an IP Address and Mask to a Physical Interface

Defining an Interface Maximum Transfer Unit (MTU)

Activating an Interface

Removing a Physical Interface IP Address

Shutting-down an Interface

Configuring a Logical Interface (VLAN)

Assigning an ID number, IP Address, and Subnet Mask to a VLAN

Defining a VLAN Maximum Transfer Unit (MTU)

Activating a VLAN

Shutting-down a VLAN

Removing a VLAN

Loopback Interface Configuration

Defining a Tunnel

Assigning a Tunnel an IP and Mask Addresses

Assigning a Tunnel a Source IP Address

Assigning a Tunnel a Destination IP Address

Defining a Tunnel Maximum Transfer Unit (MTU)

Activating a Tunnel

Shutting-down a Tunnel

Removing a Tunnel

GRE Tunnel Status Check

Removing all Interfaces

Displaying Physical Interface Information

Displaying VLAN Information

Displaying Tunnel Information

Displaying Interface Configuration File

Assigning a Default Gateway Address

Modifying the Default Gateway IP Address

Removing the Default Gateway IP Address

Adding a Static Route to the Guard Routing Table

Removing a Static Route from the Guard Routing Table

Removing all Static Routes from the Guard Routing Table

Guard Secured Shell (SSH) Configuration

Enabling a Host-to-Guard SSH Communication

Disabling a Host-to-Guard SSH Communication

Gaining an SSH Access to the Guard

Displaying SSH Keys

Removing SSH Keys

Guard TCP Proxy Configuration

Assigning the Guard a Proxy Address

Removing a Proxy Address

Guard Self-Protection

Displaying the Guard Self-protection Configuration File

Flex-filter Default Configurations

Guard Configuration

---

This chapter describes the Guard configuration procedures. These procedures lay the foundations for the Guard management and diversion related communication. In addition, these procedures define the Guard IP and proxy addresses. This chapter consists of the following sections:

•Guard Interface Configuration

•Guard Secured Shell (SSH) Configuration

•Guard TCP Proxy Configuration

•Guard Self-Protection

Guard Interface Configuration

This section describes the Guard interface configuration procedures. The Guard has several Network Interface Cards (NICs). The Eth0 and the Eth1 (Fast/Gigabit Ethernet) consist the Out-of-Band NICs used for management purposes.

The Giga0 and the Giga1 (Gigabit Ethernet) consist the In-Band NICs used for Guard management and Zone traffic transmissions.

---

Note The Guard is limited to having two In-Band interfaces Giga0 and Giga1. The user may configure one or both.

---

---

Caution When using a single In-Band interface the user must utilize Giga1.

---

The Giga0 and Giga1 provide the physical layer interface on which virtual interfaces (VLANs and tunnels) are configured. Configuring the Guard interfaces, their VLANs, and tunnels, described in the following, serve as a basis for the Diversion procedures (see Chapter 4, "Zone Traffic Diversion," for further details).

The user must configure Guard interfaces for proper Guard functioning. Interface characteristics include, but are not limited to, IP address and interface MTU.

Many features are enabled on a per-interface basis. When you enter the interface command, you must specify the interface type and number.

The following general guidelines apply to all physical and virtual interface configuration processes:

•Each interface must be configured with an IP address and an IP subnet mask.

•The user is required to activate each interface using the no shutdown command.

•After each interface major configuration change, the user is required to reload the Guard.

Guard Interface Procedures

This section describes the Guard In-Band and Out-of-Band configuration procedures. These procedures consist of assigning, removing, and modifying IP addresses of the Guard interfaces, Defining the interface MTU, VLAN, and tunnel, and removing an interface IP address.

Configuring a Physical Interface

The Guard has four physical interfaces. The Out-of-Band interfaces, Fast/Gigabit Ethernet sockets for Out-of-Band management, are eth0 and eth1.

The In-Band interfaces, copper or fiber socket, are Giga0 and Giga1.

To configure a physical interface, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# interface <if-name>

Where if-name is the interface name. Type one of the following:

•eth0—the Out-of-Band interface

•giga1—First In -Band interface

•giga0—Second In-Band interface

2. Choose ENTER. The following prompt appears:

admin@GUARD-conf-if-<if-name>#

Below is an example of the interface command (Out-of-Band interface eth0):

admin@GUARD-conf# interface eth0

admin@GUARD-conf-if-eth0#

Assigning an IP Address and Mask to a Physical Interface

To assign an IP address to a physical interface, perform the following:

1. From the interface prompt, type the following:

admin@GUARD-conf-if-eth0# ip address <ip-addr> <ip-mask> 

Where:

•ip-addr—The interface IP address

•ip-mask—The host subnet mask

2. Choose ENTER.

Defining an Interface Maximum Transfer Unit (MTU)

The user should define the interface maximum transfer unit rate.

To define the maximum transfer unit, perform the following:

1. From the interface prompt, type the following:

admin@GUARD-conf-if-eth0# mtu <integer> 

Where mtu is an integer between 576 and 16384 bytes for an Eth interface and an integer between 576 and 1824 for a Giga interface. If unassigned, the default value is 1500 bytes.

2. Choose ENTER.

Activating an Interface

After defining or shutting-down (deactivating) an interface, the user may wish to activate it.

To activate an Interface, perform the following:

1. From the interface prompt line, type the following:

admin@GUARD-conf-if-eth0# no shutdown

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes. The interface is activated and the system is reloaded. The desired interface is now active.

4. Type exit to return to the Configuration command level.

---

Note Typing the no shutdown command from any desired inactive interface prompt line activates the desired interface.

---

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Removing a Physical Interface IP Address

A user may wish to avoid using the assigned IP address of a physical interface. This may happen due to lack of sufficient number of allocated IP addresses.

To remove a physical interface IP address, perform the following:

1. From the desired physical interface prompt, type the following:

admin@GUARD-conf-if-eth0# no ip address

2. Choose ENTER.

Shutting-down an Interface

The user may wish to shut down an interface. The interface is deactivated but the Guard retains the interface data.

To shut-down (deactivate) an interface, perform the following:

1. From the interface prompt, type the following:

admin@GUARD-conf-if-eth0# shutdown

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later.

3. Type yes. The interface is deactivated and the system is reloaded. After a few seconds the Configuration command level prompt appears:

admin@GUARD-conf#

---

Note Typing the shutdown command from any desired interface prompt line deactivates the desired interface.

---

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Configuring a Logical Interface (VLAN)

The user may define VLANs on the In-Band interfaces.

To define a VLAN, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# interface giga<x>.<vlan-id> 

Where:

•x—The integer number. Choose 0 or 1 for the In-Band interface.

•vlan-id—An integer VLAN ID number. The VLAN ID is a TAG IEEE 802.1Q number.

2. Choose ENTER. Below is an example of a configuration VLAN 2 on the giga1 interface interface command implementation:

admin@GUARD-conf# interface giga1.2

admin@GUARD-conf-if-giga1.2#

Assigning an ID number, IP Address, and Subnet Mask to a VLAN

Working in a VLAN environment, the user may wish to assign IP address to every VLAN configured on the In-Band interface.

1. Type the following to assign an IP address and mask to the VLAN:

admin@GUARD-conf-if-giga1.2# ip address <ip-addr> <ip-mask>

Where:

•ip-addr—The VLAN IP address

•ip-mask—The host subnet mask

If not specified, the Guard assumes the default subnet mask of 255.255.255.255.

2. Choose ENTER.

Defining a VLAN Maximum Transfer Unit (MTU)

The user may wish to define the VLAN maximum transfer unit rate.

To define the VLAN maximum transfer unit, perform the following:

1. From the below prompt, type the following:

admin@GUARD-conf-if-giga1.2# mtu <integer>

Where integer is an integer between 576 and 1824 bytes. If unassigned the default value is 1500 bytes.

2. Choose ENTER.

Activating a VLAN

After initial VLAN configuration or shutting-down (deactivating) a VLAN the user may wish to activate it.

To activate an Interface, perform the following:

1. From the below sample VLAN prompt line, type the following:

admin@GUARD-conf-if-giga1.2# no shutdown

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes. The VLAN is activated, the configuration is changed and the system is reloaded. After a few seconds the following prompt appears:

admin@GUARD-conf-if-giga1.2#

The desired VLAN is now active.

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Shutting-down a VLAN

The user may wish to shut down (deactivate) a VLAN. In that case the VLAN is deactivated but the Guard retains the VLAN data.

To shut-down (deactivate) a VLAN, perform the following:

1. From the below sample prompt, type the following:

admin@GUARD-conf-if-giga1.2# shutdown

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes. The VLAN is deactivated, the configuration is changed and the system is reloaded. After a few seconds the following prompt appears:

admin@GUARD-conf-if-giga1.2#

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

The VLAN is deactivated. Typing the shutdown command from any desired VLAN prompt line deactivates it.

Removing a VLAN

The user may wish to erase a specified VLAN. The removal process is irreversible.

To erase a VLAN, perform the following:

1. From the Configuration command group level prompt line, type the following:

admin@GUARD-conf# no interface giga<x>.<vlan-id> 

Where:

•x—The integer number. Choose 0 or 1 for the In-Band interface.

•vlan-id—An integer VLAN ID number. The VLAN ID is a TAG IEEE 802.1Q number.

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later.

3. Type yes. The following prompt appears after a few seconds:

admin@GUARD-conf#

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Loopback Interface Configuration

The user may configure a Loopback interface. This interface is utilized by the Long Diversion procedure.

To configure the Loopback interface, perform the following:

1. From the Configuration command group level, type the following:

admin@Guard-conf# interface <if-name>

Where if-name is the loopback interface name. The name consists of lo:integer (for example, lo:5)

2. Choose ENTER. The following prompt appears:

admin@Guard-if-<if-name>#

Below is an example of a configuration lo:0 interface.

admin@GUARD-conf# interface lo:0

admin@GUARD-conf-if-lo:0#

3. Type in the loop back interface IP address and subnet mask:

admin@Guard-if-<if-name># ip address <ip-addr> <ip-mask>

Where:

•ip-addr—The interface IP address

•ip-mask—The host subnet mask

4. Choose ENTER.

5. Type exit to exit and return to the Configuration command group level and choose ENTER. The following prompt message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later.

6. Type yes and choose ENTER.

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

To remove the loopback interface, perform the following:

1. From the Configuration command group level, type the following:

admin@Guard-conf# no interface <if-name>

Where if-name is the loopback interface name.

2. Choose ENTER. The following prompt appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later.

3. Type yes. The loop back interface is removed, the configuration is changed and the system is reloaded.

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

---

Caution Reloading affects the Guard configurations together with deactivating the Learning and the Protection procedures.

---

Defining a Tunnel

The user may wish to configure a tunnel (of a GRE or an IPIP type) for its later-on zone diversion procedure (see Chapter 4, "Zone Traffic Diversion," for further details). The first step in the tunnel configuration is defining a name and a type for the tunnel.

To define a name and a type to a tunnel, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# interface gre<number> | ipip<number>}

Where:

•gre<number>—An integer number between 0 and 1024 bytes assigned to a GRE tunnel type.

•ipip<number>—An integer number between 0 and 1024 bytes assigned to an IPIP tunnel type.

2. Choose ENTER. Below is an example of the interface command implementation:

admin@GUARD-conf# interface gre2

admin@GUARD-conf-if-gre2#

The example in this section displays configuration tunnel gre2.

Assigning a Tunnel an IP and Mask Addresses

The user should now assign an IP address to the newly configured tunnel.

To assign an IP address to a tunnel, perform the following:

1. From the tunnel prompt, type the following:

admin@GUARD-conf-if-gre2# ip-address <ip-addr> <ip-mask>

Where:

•ip-addr—The tunnel assigned IP address

•ip-mask—The host subnet mask

---

Note If not specified, the Guard assumes a default subnet mask of 255.255.255.255.

---

2. Choose ENTER.

Assigning a Tunnel a Source IP Address

The user should now assign the tunnel a source IP.

To assign a tunnel a source IP, perform the following:

1. From the below prompt, type the following:

admin@GUARD-conf-if-gre2# tunnel source <source ip>

Where source ip is a tunnel source IP address.

2. Choose ENTER.

Assigning a Tunnel a Destination IP Address

The user should now assign the tunnel a destination IP.

To assign a tunnel a destination IP, perform the following:

1. From the tunnel prompt, type the following:

admin@GUARD-conf-if-gre2# tunnel destination <destination ip>

Where destination ip is a destination IP address.

2. Choose ENTER. The following prompt appears:

admin@GUARD-conf-if-gre2#

Defining a Tunnel Maximum Transfer Unit (MTU)

The user may now define the tunnel maximum transfer unit rate.

To define the tunnel maximum transfer unit, perform the following:

1. From the tunnel prompt, type the following:

admin@GUARD-conf-if-gre2# mtu <integer>

Where mtu is an integer between 556 and 1804 bytes for an IPIP tunnel and an integer between 552 and 1800 bytes for a GRE tunnel. If unassigned, the default value for an IPIP tunnel is 1480 bytes and 1476 bytes for a GRE tunnel.

2. Choose ENTER.

Activating a Tunnel

After initial configuration or shutting-down (deactivating) a tunnel the user may wish to activate it.

To activate a tunnel, perform the following:

1. From the tunnel prompt, type the following (sample):

admin@GUARD-conf-if-gre2# no shutdown

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes. The tunnel is activated, the configuration is changed and the system is reloaded.

The desired tunnel is now active.

---

Note Typing anything other than yes results in a configuration change but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Shutting-down a Tunnel

The user may wish to shut-down (deactivate) a tunnel. In that case the tunnel is deactivated but the Guard retains the tunnel data.

To shut-down (deactivate) a tunnel perform the following:

1. From the below sample prompt, type the following:

admin@GUARD-conf-if-gre2#  shutdown

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes. The tunnel is deactivated, the configuration is changed and the system is reloaded.

The tunnel (in this case the GRE tunnel) is deactivated. Typing the shutdown command from any desired tunnel prompt line deactivates it.

---

Note Typing anything other than yes results in a configuration change but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Removing a Tunnel

The user may wish to erase a specified tunnel. The removal process is irreversible.

To erase a tunnel, perform the following:

1. From the Configuration command group level prompt line, type the following:

admin@GUARD-conf# no interface {gre<number> | ipip<number>}

Where:

•gre<number>—An integer number between 0 and 1024 bytes assigned to a GRE tunnel type.

•ipip<number>—An integer number between 0 and 1024 bytes assigned to a IPIP tunnel type.

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes the following prompt appears after a few seconds:

admin@GUARD-conf#

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

GRE Tunnel Status Check

The user is able to apply a "keepalive" check on a desired GRE tunnel. The Guard applies the check for a predefined number of times at a predefined period of time. When the check returns no answer after the configured numbered of times the Guard stops using the tunnel for injection. If no other means of traffic injection exist the Guard stops the zone traffic diversion! If the tunnel end returns the `keepalive' message the Guard activates the tunnel and resumes the traffic diversion.

To apply a GRE tunnel `keepalive' check, perform the following:

1. From the desired GRE tunnel prompt, type the following (sample):

admin@GUARD-conf-if-gre2# keepalive [<refresh-time> [<retries>]] 

Where:

•refresh-time—(Optional) The time span between keepalive times. This is an integer ranging between 1 to 32767 seconds.

---

Note When unspecified the default is 3 seconds.

---

•retries—(Optional) The number of checks. This is an integer ranging between 1 and 255.

---

Note When unspecified the default is 10.

---

2. Choose ENTER. The following, sample, prompt appears:

admin@GUARD-conf-if-gre2#

To stop applying a `keepalive' procedure, perform the following:

1. From the desired GRE tunnel prompt, type the following (sample):

admin@GUARD-conf-if-gre2# no keepalive

2. Choose ENTER. The following prompt appears:

admin@GUARD-conf-if-gre2#

---

Note The user will be required to reload the Guard for keepalive configuration change to take effect.

---

Removing all Interfaces

The user may remove all logical interfaces.

---

Note If the user tries to remove eth0, eth1, giga0 or giga1 physical interfaces the following message is displayed:

You may not remove a physical interface.
Use 'shutdown' from the interface prompt to shut the interface down.

---

To remove all logical interfaces, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# no interface *

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later.

3. Type yes. All logical interfaces are removed, the configuration is changed and the system is reloaded. After a few seconds the following prompt appears:

admin@GUARD-conf#

---

Note Typing anything other than yes results in a configuration change but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Displaying Physical Interface Information

The user may wish to display information relating to a specified physical interface.

To display information relating to a physical interface, perform the following:

1. From the below sample interface prompt line, type the following:

admin@GUARD-conf-if-eth0# show

2. Choose ENTER. The following sample screen appears:

admin@GUARD-conf-if-eth0# show

eth0      Link encap:Ethernet  HWaddr 00:02:55:7B:CA:FC

          inet addr:10.10.10.33  Bcast:10.255.255.255  
Mask:255.0.0.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:160467 errors:0 dropped:0 overruns:0 frame:0

          TX packets:15858 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:100

          RX bytes:42499911 (40.5 Mb)  TX bytes:1158875 (1.1 Mb)

          Interrupt:29 Base address:0x2500 Memory:f9ee0000-0

admin@GUARD-conf-if-eth0#

Displaying VLAN Information

The user may wish to display information relating to a specified VLAN.

To display information relating to a VLAN, perform the following:

1. From the below sample prompt line, type the following:

admin@GUARD-conf-if-giga1.3# show

2. Choose ENTER. The following sample screen appears:

admin@GUARD-conf-if-giga1.3# show

 VLAN      : giga1.3

 IP ADDRESS: 192.168.100.31

 MASK      : 255.255.255.0

admin@GUARD-conf-if-giga1.3#

Displaying Tunnel Information

The user may wish display information relating to a specified tunnel.

To display information relating to a tunnel, perform the following:

1. From the below sample prompt line, type the following:

admin@GUARD-conf-if-gre8# show

2. Choose ENTER. The following sample screen appears:

admin@GUARD-conf-if-gre8# show

 TUNNEL gre8:

 IP ADDRESS 192.168.122.2 MASK 255.255.255.252

 Destination 192.168.8.88

 Source 192.168.8.2

admin@GUARD-conf-if-gre8#

Displaying Interface Configuration File

The user may display a desired interface configuration file. This file includes all the configuration information relating to the desired physical interface, VLANs or tunnels.

To display a desired interface configuration file, perform the following:

1. From the Global command group level, type the following;

admin@GUARD# show running-config interface <interface-name>

Where interface-name is the desired interface name

2. Choose ENTER. The following partial sample screen appears:

admin@GUARD# show running-config interface gre8

interface gre8

  ip address 192.168.122.2 255.255.255.252

  no shutdown

  tunnel destination 192.168.8.88

  tunnel source 192.168.8.2

exit

admin@GUARD#

Assigning a Default Gateway Address

The user should assign a default Gateway to the Guard. The Guard's default Gateway address is usually the Guard's adjacent router. The Guard default Gateway address must be on the same network as one of the Guard interfaces' IP addresses.

---

Note Do not assign an IP address to a default Gateway while the Guard is in protection mode.

---

To assign a default Gateway address, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# default-gateway <ip-addr>

Where ip-addr is the default Gateway IP address.

2. Choose ENTER.

Modifying the Default Gateway IP Address

The user may wish to modify the default Gateway IP address.

To modify the default Gateway IP address, repeat the procedure of assigning a default Gateway address only this time with the modified Gateway address.

Removing the Default Gateway IP Address

The user may wish to remove the specified default Gateway's IP address.

To remove the default Gateway IP address, perform the following:

1. From the Configuration group command level, type the following:

admin@GUARD-conf# no default-gateway

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later.

3. Type yes.

---

Note Typing anything other than yes results in a configuration change, but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Adding a Static Route to the Guard Routing Table

The user may add a static route to the Guard routing table. This route may relate to handling packets via an adjacent router or via a Guard physical interface, VLAN, or, tunnel configurations.

To add a static route to the Guard routing table, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# ip route <ip-addr> <ip-mask> <nexthop-ip> 
[<if-name>]

Where:

•ip-addr—The route network destination. The destination can be an IP network address (where the host bits of the network address are set to 0) or an IP address for a host route.

•ip-mask—The subnet mask associated with the network destination.

•nexthop-ip—The forwarding or the nexthop-IP address over which the set of addresses defined by the network destination and subnet mask are reachable. The nexthop IP address should be within the interface subnet (see if-name further down in this table). For local subnet routes, the nexthop-IP address is the IP address assigned to the interface that is attached to the subnet. For remote routes, available across one or more routers, the nexthop-IP address is a directly reachable IP address that is assigned to a neighboring router.

•if-name—(Optional) The Guard interface, VLAN, or tunnel (see the sections relating to the Guard Interfaces, VLAN, and tunnel in this chapter for further details).

2. Choose ENTER.

---

Note In case of a problem (i.e. no route to the next-hop exists) the Guard prompts the error message: No route to next hop, route already exists or invalid interface entered.

---

Removing a Static Route from the Guard Routing Table

The user may remove a specific static route from the Guard routing table.

To remove a specific static route from the Guard routing table, perform the following:

1. From the Configuration command group level, type the to-be-removed static route parameters:

admin@GUARD-conf# no ip route <ip-addr> <ip-mask> <nexthop-ip> 
[<if-name>]

Where:

•ip-addr—The route network destination. The destination can be an IP network address (where the host bits of the network address are set to 0) or an IP address for a host route.

•ip-mask—The subnet mask associated with the network destination.

•nexthop-ip—The forwarding or the nexthop-IP address over which the set of addresses defined by the network destination and subnet mask are reachable. The nexthop IP address should be within the interface subnet (see if-name further down in this table). For local subnet routes, the nexthop-IP address is the IP address assigned to the interface that is attached to the subnet. For remote routes, available across one or more routers, the nexthop-IP address is a directly reachable IP address that is assigned to a neighboring router.

•if-name—(Optional) The Guard interface, VLAN, or tunnel (see the sections relating to the Guard Interfaces, VLAN, and tunnel in this chapter for further details).

2. Choose ENTER.

Removing all Static Routes from the Guard Routing Table

The user may remove all static routes from the Guard routing table.

To remove all static routes from the Guard routing table, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# no ip route *

2. Choose ENTER.

Guard Secured Shell (SSH) Configuration

The Guard enables the user to have a Secured Shell (SSH) management access rather than accessing the Guard via the console. This section describes the SSH communication configuration procedures and the Guard SSH access procedure.

---

Note If the user prefers not to implement the SSH communication option the Guard is operable via the console (see the "Guard Access Options" section in Chapter 2, "Initial Procedures").

---

Enabling a Host-to-Guard SSH Communication

To establish an SSH communication to the Guard from any network, perform the following:

1. From the configuration command group level, type the following:

admin@GUARD-conf# permit ssh <ip-addr> [<ip-mask>]

Where:

•ip-addr—The host IP address

•ip-mask—(Optional) The host subnet mask

---

Note If not specified, the Guard assumes a default subnet mask of 255.255.255.255.

---

2. Choose ENTER.

Disabling a Host-to-Guard SSH Communication

The user may disable a specific host to Guard SSH communication.

To disable a host to Guard SSH communication, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# no permit ssh <ip-addr> [<ip-mask>]

Where:

•ip-addr—The host IP address. Use `*' to disable host to Guard ssh communication from all IP addresses.

•ip-mask—(Optional) The host subnet mask.

---

Note If not specified, the Guard assumes a default subnet mask of 255.255.255.255.

---

2. Choose ENTER.

---

Caution Disabling all host to Guard SSH communication limits the Guard access to the console only.

---

Gaining an SSH Access to the Guard

The Guard user may wish to gain access to the Guard via an SSH connection rather than a login/Password access. The following procedure enables the user to paste its public SSH key into the displayed KEY prompt thus allowing an SSH connection between the user and the Guard.

To gain an SSH access to the Guard, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# key add [<user-name>]{ssh-dsa|ssh-rsa} 
<key-string> <comment>

Where:

•user-name—(Optional) Add an SSH key for the specified user.

---

Note This option is only available from admin privilege level. If not specified, the SSH key is added for the current user.

---

•ssh-dsa | ssh-rsa—SSH key type. The Guard supports SSH2-DSA and SSH2-RSA.

•key-string—The Public SSH key created on the Detector or remote terminal.

---

Note The user must copy the complete key excluding the key type identification (ssh-rsa or ssh-dsa).

---

•comment—A device description.

2. Choose ENTER.

Below is an example of the key add command (Note: The displayed key is shortened for display purposes):

admin@GUARD-conf# key add ssh-rsa  145137971652817796205730. . . 
user@guard.com

admin@GUARD-conf#

The user now can use an SSH enabled terminal to connect with the Guard without entering a password.

Displaying SSH Keys

The user may display the SSH keys configured for the Guard.

To display the Guard SSH keys, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# show keys [<user-name>]

Where the optional user-name displays SSH keys for the specified user.

---

Note This option is only available from admin privilege level. If not specified, the current user's SSH keys are displayed.

---

2. Choose ENTER. Below is an example of the show keys command (the displayed key is shortened for display purposes):

admin@GUARD-conf# show keys

ssh-rsa 2352345234523456... user@guard.com

ssh-rsa 8756785678567856... user@guard.com

admin@GUARD-conf#

Removing SSH Keys

The user may remove the user SSH key. The User would have to authenticate upon SSH connection to the Guard.

To remove an SSH key from the Guard, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# key remove [<user-name>] <key-string>

Where:

•user-name—(Optional) Remove SSH keys for the specified user.

---

Note This option is only available from admin privilege level. If not specified, the SSH key is removed from the current user.

---

•key-string—The Public ssh key to remove.

The user pastes the corresponding SSH public key onto the KEY prompt (paste only the key without the identification field).

Below is an example of the key remove command. The User's "Richard" public SSH key is displayed and then removed:

admin@GUARD-conf# show keys Richard

ssh-rsa 2352345234523456... user@guard.com

admin@GUARD-conf# key remove Richard ssh-rsa 2352345234523456...

admin@GUARD-conf#

Guard TCP Proxy Configuration

This section describes the Guard proxy IP address procedures. The Guard proxy address is required for the proxy mode anti-spoofing protection mechanisms (see the "Diverting Traffic" and "MPLS LSP" sections in Chapter 4, "Zone Traffic Diversion,"," the "User Filter Configuration" section in Chapter 9, "Advanced Filter Procedures," and the "Proxy-Threshold" section in Chapter 10, "Advanced Policy Procedures," for further details).

Assigning the Guard a Proxy Address

The user must assign the Guard a proxy IP address.

---

Warning Zone Protection mode cannot be applied when no proxy IP address is defined.

---

---

Note Do not assign the Guard with a proxy address while the Guard is in protection mode.

---

---

Note We recommend assigning between three to four proxy addresses. The Guard may have up to ten proxy addresses.

---

---

Note The user should verify the route between every zone and the Guard proxy IP address. The Guard doesn't answer pinging to its proxy IP.

---

To assign the Guard with an address, perform the following:

1. From the Configuration command group level, type the following:

admin#GUARD-conf# proxy <ip-addr> 

Where ip-addr is the proxy IP address.

2. Choose ENTER. The following prompt message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

Type yes. 

3. Repeat steps one and two to assign additional proxy IP addresses.

---

Note Typing anything other than yes results in a configuration change but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

Removing a Proxy Address

The user may wish to remove a Guard proxy IP address.

---

Caution Removing a Guard's proxy address may impair the Guard protection.

---

To remove the Guard proxy address, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# no proxy <ip-addr>

Where ip-addr is the specified proxy IP address to be removed. Use `*' to remove all Guard proxy IP addresses.

2. Choose ENTER. The following message appears:

For changes to take effect you need to reload the software.

Type 'yes' to reload now, or any other key to reload manually 
later

3. Type yes.

---

Note Typing anything other than yes results in a configuration change but the change does not take effect unless the user issues the reload command. See the "Reloading the Guard Modified Configurations" section in Chapter 2, "Initial Procedures," for further details.

---

---

Caution Removing all of the Guard's proxy addresses may compromise the Guard protection.

---

Guard Self-Protection

The Guard as a network element having an independent IP address (see the "Assigning an IP Address and Mask to a Physical Interface" section for further details), exposes the Guard to a potential DDoS attack. The Guard is, by default, capable of defending itself against such an attack. However, the Guard enables the user to access its self-defense protection for configurations.

---

Caution We strongly advise against changing the Guard's self-protection default configurations. Unnecessary configurations may result in seriously compromising the Guard self-protection ability!

---

To change the Guard self-protection configurations, perform the following:

1. From the Configuration command group level, type the following:

admin@GUARD-conf# self-protection

2. Choose ENTER. The following prompt appears:

admin@GUARD-conf-self-protection#

The set of commands open for the user to configure is identical to an ordinary zone.

The following table displays the set of commands with corresponding references:

Command	Reference
bypass-filter	See the "Bypass Filter Configuration" and "Removing a Bypass Filter" sections in Chapter 9, "Advanced Filter Procedures"
copy-services	See the "Copying Policies" section in Chapter 10, "Advanced Policy Procedures"
description	See the "Describing a Zone" section in Chapter 5, "Zone Configurations"
dynamic-filter	See the "Configuring the Guard Dynamic Filters" and "Removing a Dynamic Filter" sections in Chapter 9, "Advanced Filter Procedures"
end	See the "Issuing Commands in the CLI" section in Chapter 2, "Initial Procedures"
exit	See the "Issuing Commands in the CLI" section in Chapter 2, "Initial Procedures"
flex-filter	See the "Flex Filter Configuration" and "Removing a Flex Filter" in Chapter 9, "Advanced Filter Procedures"
interactive	See Chapter 11, "Interactive Recommendations Mode"
ip	See the "Removing a Zone's IP Address" section in Chapter 5, "Zone Configurations"
learning	See the "Zone Traffic Learning" section in Chapter 5, "Zone Configurations" and Chapter 10, "Advanced Policy Procedures"
no	See the references relating to: bypass-filter, flex-filter, learning, service, dynamic-filter, ip, protect, and user-filter
policy	See Chapter 10, "Advanced Policy Procedures"
policy-template	See Chapter 10, "Advanced Policy Procedures"
protect	See the "Protecting the Zone" section in Chapter 5, "Zone Configurations"
protection-end-timer	See the "Protection Termination Timer" section in Chapter 5, "Zone Configurations"
rate-limit	See the "Defining the Zone Bandwidth" section in Chapter 5, "Zone Configurations"
recommendation	See Chapter 11, "Interactive Recommendations Mode"
show	See the "Issuing Commands in the CLI" section in Chapter 2, "Initial Procedures"
user-filter	See the "User Filter Configuration" and "Removing a User Filter" sections in Chapter 9, "Advanced Filter Procedures"
zone	See Chapter 5, "Zone Configurations"

Displaying the Guard Self-protection Configuration File

The user may display the configuration file containing the Guard self-protection configurations.

To display the Guard self-protection configuration file, perform the following:

1. From the Global, Configuration and Zone command group levels, type the following:

admin@GUARD# show running-config self-protection

2. Choose ENTER. The following, partial, sample, screen appears:

self-protection

 protection-end-timer forever

 rate-limit 8000 10000 pps

 description  Guard self protection

 flex-filter drop not ((ip proto 6 and src port 179 and tcp[13:1] 
& 18 != 2)or(ip proto 6 an

d src port 23 and tcp[13:1] & 18 != 2)or(ip proto 6 and src port 
21 and tcp[13:1] & 18 != 2)

or(ip proto 6 and src port 20)or(ip proto 6 and src port 22 and 
tcp[13:1] & 18 != 2)or(ip pr

oto 6 and dst port 22)or(ip proto 6 and dst port 443)or(ip proto 
1)or(ip proto 17 and dst po

rt 161)or(ip proto 17 and dst port 123)or(ip proto 17 and src port 
123)or(ip proto 17 and sr

c port 520)or(ip proto 17 and dst port 520)or(ip proto 89))

 no bypass-filter *

 no user-filter *

 user-filter 10 basic/reset *  6 22 no-fragments

 user-filter 20 basic/reset *  6 443 no-fragments

 user-filter 30 basic/reset *  6 1112 no-fragments

 ... ... ...

 user-filter 90 permit *  89 * no-fragments rate-limit 500 500 pps

 user-filter 100 drop *  * * any-fragments

 policy-template tcp_services_ns 5 1.0 enabled

 policy-template udp_services 5 1.0 enabled

 ... ... ...

 policy-template tcp_not_auth -1 -1 enabled

 policy-template fragments -1 -1 enabled

 policy-template other_protocols -1 -1 enabled

 policy fragments/any/analysis/auth_pkts/dst_ip 50.0 
to-user-filters 600 active

... ... ... 

Flex-filter Default Configurations

The Guard has its Flex filter configured, by default, to block (drop) certain traffic flows. The below table demonstrates the Flex filter default configuration:

SERVICE	IP-PROTO	SRC-PORT	DST-PORT	ALLOW-SYN
bgp	6	179	*	no
telnet	6	23	*	no
ftp-control	6	21	*	no
ftp-data	6	20	*	yes
tacacs	6	49	*	yes
ssh	6	22	*	no
ssh	6	*	22	yes
https	6	*	443	yes
icmp	1	*	*	yes
snmp	17	*	161	yes
ntp	17	*	123	yes
ntp	17	123	*	yes
ospf	89	*	*	yes
rip	17	520	*	yes
rip	17	*	520	yes
gre	47	*	*	yes

The Flex filter has been configured to accomplish the following:

•BGP communication with the Divert-from router's port 179 (see Chapter 4, "Zone Traffic Diversion," for further details)—The Flex filter would block SYN packets arriving from the Divert-from router's port 179.

•Telnet communication with Divert-from router's port 23 (see Chapter 4, "Zone Traffic Diversion," for further details)—The Flex filter would block SYN packets arriving from the Divert-from router's port 23.

•Communication with an FTP server port 2—The Flex filter would block the SYN packets belonging to the FTP control flow coming from source port 21 and allow SYN packets belonging to the FTP data flow coming from source port 20.

•Secured Shell (SSH) communication initialized by the Guard (see the "Guard Secured Shell (SSH) Configuration" section in this chapter for further details)—The Flex filter would block SYN packets coming from source port 22.

•Secured Shell (SSH) communication flowing to the Guard (seethe "Guard Secured Shell (SSH) Configuration" section in this chapter for further details)—The Flex filter would allow in SYN packets coming to the Guard port 22.

•HTTP secured (HTTPS) communication flowing to the Guard—The Flex filter would allow SYN packets coming to the Guard port 443.

•ICMP communication—The Flex filter would block SYN packets flowing to the Guard.

•SNMP communication flowing to the Guard—The Flex filter would allow SYN packets flowing to Guard port 161.

•NTP communication initialized by the Guard (see the "Time Related Commands" section in Chapter 2, "Initial Procedures," for further details)—The Flex filter would block SYN packets coming from source port 123.

•NTP communication flowing to the Guard (see the "Time Related Commands" section in Chapter 2, "Initial Procedures," for further details)—The Flex filter would block SYN packets coming to the Guard port 22.

•OSPF communication—The Flex filter would block SYN packets flowing through the Guard, while allowing Guard OSPF communication to proceed.