Table Of Contents

On-Demand Protection

Overview

Zone Definition

Describing a Zone

Defining the Zone Bandwidth

Defining the Zone IP Address

Zone Protection

Protecting a Specific Zone

Traffic Analysis

Problem Analysis

Diversion Problem

Traffic Blockage Problem

Attack Mitigation Verification

Attack Type Characterization

Spoofed ?

Spoofed

HTTP Zombie Attack

Non-spoofed

On-Demand Protection

---

This chapter describes the On-Demand Protection feature and details the protection process flow, the procedure stages implementation, and the traffic analysis that accompanies a DDoS attack under such circumstances.

Overview

The Guard has its `On-Demand' protection to answer the situation in which the zone is under attack while the Guard has not completed its Learning phase and so has not adopted its protection policy to suite the zone traffic.

Figure 6-1 displays the On-Demand protection process flow and its related troubleshooting procedure:

Figure 6-1 On-demand Protection Flow and Analysis

The On-Demand Protection procedure consist of the following phases:

•Zone procedures—These procedures prepare the zone for a quick learning-independent protection. This phase includes the zone configuration and zone protection activation.

•Traffic analysis—This phase consists of zone traffic analysis to verify proper overall procedure flow. This is performed via counter and Dynamic filter display.

•Troubleshooting—This phase consists of a filter and counters analysis to deduce the causes for diversion and traffic blockage problems.

•Mitigation checkup—This phase verifies the proper functioning of the Guard protection in that it checks that attack mitigation is in progress. This is based on an analysis of the displayed counters and Dynamic filters.

•Attack analysis—This phase consist of two procedures. The first characterizes the attack as a TCP or a non-TCP. The second applies to a TCP attack and checks whether the attack is spoofed or non-spoofed. These checks are based on an analysis of the show zone and the show zone dynamic-filter commands.

Zone Definition

An attack prior to the Learning phase requires a new zone definition. This is to set up a zone configuration that would implement Cisco set of protection measures suited to such a situation.

To define the zone, perform the following:

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

admin@GUARD-conf# zone <new-zone-name> [<template>|copy-from 
<base-zone-name>][interactive]

Where:

•new-zone-name—A zone name string. An alphanumeric string should start with a letter, hold no spaces, and should be limited to a length of up to 63 characters. The string may contain underscores.

•template—(Optional) A template that defines the zone configuration. Options are:

DEFAULT—The Guard default zone template

TCP_NO_PROXY—A template designed for a zone for which no TCP proxy is to be used. This template is may be used if the zone is moderated according to IP addresses such as an Internet Relay Chat (IRC) server-type zone (see Chapter 10, "Advanced Policy Procedures," for further details).

Bandwidth-limited Link Templates—Templates designed and specifically tailored for On-Demand protection of large subnets segmented according to zones with known bandwidth. Protection for the zone should be assumed for the attacked subnet or range. It is recommended to define such a zone on the Detector with protect-ip-state of only-dest-ip (See the "Guard-protection Activation Forms" section in the Cisco Traffic Anomaly Detector User Guide for further details).

The following bandwidth-limited link templates are available for 128K, 1M, 4M, and 512K links respectively:

LINK_128K

LINK_1M

LINK_4M

LINK_512K

---

Note Learning Phase 1, policy construction, cannot be performed for these templates.

---

---

Note If no zone template is specified, the zone will be defined using the Guard DEFAULT zone template.

---

•base-zone-name—(Optional) The name of a desired zone used as a template for the new zone.

•interactive—(Optional) The operation mode of the new zone is set to interactive. See Chapter 11, "Interactive Recommendations Mode," for further details.

---

Note Choosing Enter after inserting the new zone name defines a zone by the Guard default zone template.

---

2. Choose the desired option and choose ENTER or directly choose ENTER. Below is an example of the zone command implementation:

admin@GUARD-conf# zone scannet 

admin@GUARD-conf-zone-scannet#

Describing a Zone

The user may add a description to the new zone for identification purposes.

To add a description to a zone, perform the following:

1. From the Zone command level, type the following:

admin@GUARD-conf-zone-<zone-name># description <string>

Where string is a string describing the zone. The string length is limited to a maximum of 80 characters.

2. Choose ENTER. The following sample prompt appears:

admin@GUARD-conf-zone-scannet# description Scannet Zone used for 
demonstration purposes

Defining the Zone Bandwidth

The user now defines the bandwidth allowed to pass to the zone according to the traffic amount the zone can handle. The user should specify both the traffic rate-limit and the burst size.

---

Note We recommend to set the bandwidth value to the highest bandwidth measured entering the zone. If unknown, leave the default bandwidth value (200.000 pps).

---

To define the zone bandwidth, perform the following:

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

admin@GUARD-conf-zone-<zone-name># rate-limit {no-limit | <rate> 
<burst-size> <rate-units>}

Where:

•no-limit—The zone is defined with no rate limit.

•rate—The amount of traffic (in the units specified below) allowed to pass to the zone. The amount is specified by an integer.

•burst-size—The highest traffic peak allowed passing to the zone. The peak is specified by an integer. The units are Bits, kilo-bits, kilo-packets, mega-bits, and packets in correspondence to the rate units.

•rate units—Rate units. The units are:

bps—Bits per second

kbps—Kilo bits per second

kpps—Kilo packets per second

mbps—Mega bits per second

pps—Packets per second

2. Choose ENTER. The following sample prompt appears:

admin@GUARD-conf-zone-scannet# rate-limit 100000 230000 pps

admin@GUARD-conf-zone-scannet#

---

Note If the measurement units are not specified, the default bandwidth measurement unit is set to Mbps.

It is recommended to change a zone's bandwidth when the zone is in the unprotected mode. Otherwise, the change takes effect after the zone protection is deactivated.

---

Defining the Zone IP Address

The user now defines a zone IP address to enable the Guard to perform traffic learning and protection procedures.

To define the zone IP address, perform the following:

1. From the Zone or Configuration command groups level, type the following:

admin@GUARD-conf-zone-<zone-name># ip address <ip-addr> 
[<ip-mask>] 

Where:

•ip-addr—The zone IP address

•ip-mask—(Optional) The zone IP subnet mask.

If no mask is specified the Guard assumes the default subnet mask 255.255.255.255.

2. Choose ENTER. The following sample prompt appears:

admin@GUARD-conf-zone-scannet# ip address 10.10.10.34

admin@GUARD-conf-zone-scannet#

---

Note The user must initially configure the zone IP address when the zone is unprotected. However, the user may configure a zone's subnet IP address or its additional IP addresses when the zone is in the protected mode.

The zone IP address procedure should repeat per each zone IP address or subnet mask.

---

Zone Protection

At this stage the user activates the Guard to protect the zone.

To protect the zone, perform the following:

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

admin@GUARD# protect <zone-name> [<ip-address>]

From the Zone command group level, type the following:

admin@GUARD-conf-zone-<zone-name># protect

Where:

•zone-name—A desired zone name

•ip-address—(Optional) The protected zone IP address

2. Choose ENTER. The following sample prompt appears:

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

Protecting a Specific Zone

The user may require the protection of an IP-specific zone that is a part of a more comprehensive zone (i.e. a protected network environment). The Guard is given the IP address of the IP-specific zone. Such a case could, for example, be the protection of a specific zone that is a part of a protected subnet.

To protect a specific zone, perform the following:

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

admin@GUARD# protect <zone-name> <ip-addr>

Where:

•zone-name—The name of the attacked zone

•ip-addr—The IP address of the IP-specific zone that requires particular protection

2. Choose ENTER. The following sample screen appears:

admin@GUARD# protect scannet 192.168.5.6

creating zone scannet_192.168.5.6

A new zone, by a name which consists of the first 30 characters of the major zone an underscore and the IP address of the specific zone, is created.

---

Note If a zone by the same name already exists the Guard would refer to the existing zone instead of creating another zone by the same name. An IP-specific zone is removed by procedure described in the "Removing a Zone" section in Chapter 5, "Zone Configurations."

---

Traffic Analysis

At this stage, perform a zone traffic analysis to determine whether the zone protection is functioning properly. This is performed via the show counters details command. This command is issued twice in an approximate ten seconds interval to view how the zone protection is evolving.

To analyze the protected zone traffic, perform the following:

1. From the Global, or Configuration command group levels, type the following (in an interval of approximately a minute):

admin@GUARD# show zone <zone-name> counters [details|history]

From the Zone command group level, type the following:

admin@GUARD-conf-zone-<zone-name># show counters [details|history]

Where:

•zone-name—The zone name

•details—(Optional) Displays the following counters:

Malicious—The malicious portion of the traffic the Guard received.

Legitimate—The legitimate portion of the traffic the Guard received.

Received—The total traffic the Guard received.

Forwarded—The traffic the Guard forwarded to its zone or zones.

Dropped—The traffic the Guard dropped.

Replied—The traffic the Guard sent in an authentication process.

Invalid zone—Diverted traffic that is not destined to the any of the Guard's protected zones.

The counters display in packets and in Kbits units.

---

Note By default for both options, the Guard displays the traffic rates for the following counters: Malicious, Legitimate. The counters are measured in packets and in Kbits.

---

•history—(Optional) Displays the Malicious and Legitimate counter values for every minute in the past hour. The counters are measured in packets and in Kbits.

2. Choose ENTER. The following sample screens appear:

admin@GUARD-conf-zone-scannet# show counters details

                    Packets          KBits

Legitimate traffic: 74350            39009

Malicious  traffic: 121917           79568

Received   traffic: 196267           118578

Forwarded  traffic: 74350            39009

Dropped    traffic: 59553            48386

Replied    traffic: 62364            31182

Invalid    zone   : 0                0

The next sample screen follows:

admin@GUARD-conf-zone-scannet#show counters details

                    Packets          KBits

Legitimate traffic: 185898           96084

Malicious  traffic: 332540           217139

Received   traffic: 518438           313223

Forwarded  traffic: 185898           96084

Dropped    traffic: 162785           132261

Replied    traffic: 169755           84877

Invalid    zone   : 0                0

The following can be deduced from viewing both screens:

•Having received and forwarded legitimate packets (Received ¼ 0 and Legitimate ¼ 0) indicates a proper functioning of the Guard diversion mechanism.

•The received packet number is greater than the legitimate indicates a proper protection functioning. This is not an absolute indicator for fully traffic-tailored functioning and a further checkup may be required. This checkup consists of viewing the Dynamic filters (see the viewing Dynamic filter procedure in the "Traffic Blockage Problem" section in this chapter). The user should observe the following in light of both work experience and traffic knowledge:

•If a trusted IP source is blocked by a Dynamic filter the user may wish to have that source IP bypass the Guard filters (see the "Bypass Filters" section in Chapter 9, "Advanced Filter Procedures").

•If a policy has produced filters that drop too many IP flows, the user may wish to increase the policy's threshold or prevent its further production (deactivating it). See the "Disabling a Policy Template" and "Threshold" section in Chapter 10, "Advanced Policy Procedures."

In case of the above results the following stage would be an attack analysis (see the "Attack Type Characterization" section in this chapter). In the case of having other received and forwarded legitimate results refer to the "Problem Analysis" section in this chapter).

Problem Analysis

When the results of the received and legitimate packets display Received = 0 or legitimate = Constant (when measured across a time span of above 1 minute) this indicates a problem. This problem could be either or both of the following:

•A case in which the Guard does not receive the packets to the zone (Received = 0)—This indicates a diversion problem.

•A case in which the Guard receives the zone's diverted traffic packets but blocks them from being forwarded on to the zone (Received ¼ 0 and legitimate = Constant in between the time interval measurements)—This indicates a traffic blockage problem.

---

Note Since the counters show accumulated traffic a certain amount of traffic will show at the legitimate counter. However, since there is a traffic blockage problem the traffic amount remains at constant.

---

Diversion Problem

When the show zone command displays results in which the Guard does not receive any packets this also entails that no packets are forwarded on to the zone, this indicates a diversion problem (Received = 0). The screen sample below demonstrates such a case:

admin@GUARD-conf-zone-scannet#show counters details

                    Packets          KBits

Legitimate traffic: 0                0

Malicious  traffic: 0                0

Received   traffic: 0                0

Forwarded  traffic: 0                0

Dropped    traffic: 0                0

Replied    traffic: 0                0

Invalid    zone   : 0                0

In such a case, follow the diversion troubleshooting procedure (see Appendix B, "Diversion Troubleshooting").

Traffic Blockage Problem

When the show counters details command displays results in which the Guard receives the zone's diverted packets but no packets are forwarded on to the zone (Received ¼ 0 and legitimate = Constant in between measurements taken along a time interval, see the "Traffic Analysis" section in this chapter) this might indicate a block on the way of the traffic forwarded to the zone. The screen sample below demonstrates such a case:

admin@GUARD-conf-zone-scannet#show counters details

                    Packets          KBits

Legitimate traffic: 3181             8693

Malicious  traffic: 130906           358180

Received   traffic: 134087           366873

Forwarded  traffic: 3181             8693

Dropped    traffic: 130906           358180

Replied    traffic: 0                0

Invalid    zone   : 0                0

The screen sample above indicates that almost all the traffic destined to the zone is dropped. The user should scan the Dynamic filters the Guard had produced for a drop- action filter and consider, as the case may be, the following suggested actions:

•Erase the drop-action Dynamic filter

•Deactivate the protection policy that produced the drop-action Dynamic filter (avoiding taking this action would result in the drop-action filter re-appearing) so no policies of the kind that produced the drop-action Dynamic filter would be re-produced.

---

Caution Deactivating the protection policy that produced the Dynamic filter compromises the zone protection.

---

To view the Dynamic filter the Guard produced, perform the following:

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

admin@GUARD-conf-zone-<zone-name># show dynamic-filters

---

Note Issuing the show dynamic-filters command without the details option provides details on the dynamic filter, but does not provide details on the attack flow, the triggering rate and the policy which produced the Dynamic filter.

---

2. Choose ENTER. The following sample screen appears:

admin@GUARD-conf-zone-scannet#show dynamic-filters details

**** DYNAMIC FILTERS ****

ID	Action	Exp Time	Source IP	Source Mask	Proto	DPort	Frg	RxRate(pps)
25	drop	599	192.168.100.45	255.255.255.255	6	*	no	9

Attack flow: 6  192.168.100.45  * 192.168.100.34  80  no fragments

Triggering rate: 105.00 Threshold: 10.00

Policy: tcp_connections/any/strong/in_conns/src_ip

The sample screen indicates that the drop-action Dynamic filter has dropped the malicious traffic.

To remove a specific Dynamic filter, perform the following:

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

admin@GUARD-conf-zone-<zone-name># no dynamic-filter 
<dynamic-filter-id>

Where dynamic-filter-id is the specified dynamic filter ID. This is a number (integer) assigned by the Guard. In this case the number is 25.

2. Choose ENTER.

To deactivate the protection policy that produced the drop-action Dynamic filter, perform the following:

1. Enter the policy command group level and from the Zone command group level, type the following:

admin@GUARD-conf-zone-<zone-name># policy <policy-name>

Where policy-name is the name of the policy that you wish to deactivate.

2. Choose ENTER. The following sample appears:

admin@GUARD-conf-zone-scannet# policy tcp_connections/any

 /strong/in_conns/src_ip

admin@GUARD-conf-zone-scannet-policy-/tcp_connections/any

/strong/in_conns/src_ip#

3. From the Policy command group level, type the following:

admin@GUARD-conf-zone-<zone-name>-policy-<policy-name># state 
inactive

---

Note "tcp_connections/any/strong/in_conns/src_ip" is the policy that produced the drop-action Dynamic filter. Deactivating it results in the policy stopping from re-producing the drop-action Dynamic filter. To activate the policy issue state active from the Policy command group level.

---

---

Note In a situation where several policies, which are part of the same policy branch, produce drop-action Dynamic filters, a policy branch can be deactivated. For example, the policy branch "tcp_connections/any/strong" can be deactivated. To deactivate a policy branch, repeat the above mentioned procedures using <policy-branch-name> instead of <policy-name>.

---

4. Choose ENTER.

Attack Mitigation Verification

This is the stage in which the user verifies whether the Guard mitigates the attack. This stage consists of checking the ratio between the received and the legitimate packets, the status of the Dynamic filter, the proper functioning of the anti-zombie mechanisms as reflected in the replied packets value and the Dynamic filters, and the proper functioning of the Guard anti-spoofing and mechanisms as reflected in the replied packets value and in the User filters data. An attack mitigation verification procedure is performed via issuing the show zone command.

To verify an attack mitigation, perform the following:

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

admin@GUARD# show zone <zone-name>

Where zone-name is the name of the desired zone.

2. Choose ENTER. The following sample screen appears:

admin@GUARD-conf-zone-scannet#show

... ... ...

                    pps              bps

Legitimate traffic: 3181             8693

Malicious  traffic: 32162            16467404

There are 2 dynamic filters

**** USER FILTERS ****

Row	Source IP	Source Mask	Prot o	DPort	Frg	Action	Rate	Burst	Units	RxRate(pps)
10	*		6	80	no	basic/redirect				32127
20	*		6	8080	no	basic/redirect				0

... ... ...

admin@GUARD-conf-zone-scannet#

The above sample screen indicates the following:

•The Guard produced 2 Dynamic filters. This is a result of an active protection in progress (see Chapter 9, "Advanced Filter Procedures," for further details).

•The User filters counters (marked in bold) are greater than zero indicating that the Guard anti-spoofing mechanisms are in progress.

3. From the Zone command group level, type the following:

admin@GUARD-conf-zone-<zone-name># show counters details

The following sample screen appears:

admin@GUARD-conf-zone-scannet#show counters details

                    Packets          KBits

Legitimate traffic: 6208             3104

Malicious  traffic: 14905635         7452817

Received   traffic: 14911843         7455921

Forwarded  traffic: 6208             3104

Dropped    traffic: 0                0

Replied    traffic: 14905635         7452817

Invalid    zone   : 0                0

•The REPLIED packets counter (marked in bold) that is greater than zero also indicates that the anti-spoofing mechanisms are in progress.

•The number of the received packets is greater than the number of the legitimate (forwarded) and the number of the replied packets is greater than zero (Received > Legitimate and Replied > 0). This means that the Guard has designated part of the traffic as suspicious and operated its anti-spoofing mechanisms. As a result, there is a number of replied packets, namely, a number of packets that the Guard decided to authenticate (Replied > 0).

Attack Type Characterization

This is the stage in which the user characterizes the attack type as being a TCP or non-TCP to gain more information. This is performed via an analysis of the following:

•The User filters

•The Dynamic filters

View the following sample screen:

admin@GUARD-conf-zone-scannet#show

... ... ...

                    pps              bps

Legitimate traffic: 3181             8693

Malicious  traffic: 32162            16467404

There are 2 dynamic filters

**** USER FILTERS ****

Row	Source IP	Source Mask	Proto	DPort	Frg	Action	Rate	Burst	Units	RxRate(pps)
10	*		6	80	no	basic/redirect				32127
20	*		6	8080	no	basic/redirect				0

... ... ...

admin@GUARD-conf-zone-scannet#

The above sample screen indicates that the User filter (row 10 in this case) counters indicate that a TCP protocol (protocol number 6) type traffic was traced to be suspicious and therefore filtered.

See the "Spoofed ?" section in this chapter for further details about determining whether the TCP traffic is spoofed or not. The following sample screen displays information about a zone under a non-TCP typed attack:

admin@GUARD-conf-zone-scannet#show

... ... ...

                    pps              bps

Legitimate traffic: 1724             947140

Malicious  traffic: 10363            6532259

There are 6 dynamic filters

**** USER FILTERS ****

Row	Source IP	Source Mask	Proto	DPort	Frg	Action	Rate	Burst	Units	RxRate(pps)
130	*		1	*	no	permit	300	300	pps	3977
140	*		*	*	no	basic/default				0

... ... ...

admin@GUARD-conf-zone-scannet#

The above sample screen indicates that the User filter (row 130 in this case) counter (marked in bold) indicates that a protocol (Proto) number one that is an ICMP protocol-typed traffic was traced to be suspicious and, therefore, filtered.

The following sample screen displays information about the Dynamic filters produced in the case of a non-TCP attack:

admin@GUARD-conf-zone-scannet#show dynamic-filters details

**** DYNAMIC FILTERS ****

ID	Action	Exp Time	Source IP	Source Mask	Proto	DPort	Frg	RxRate(pps)
6	to-use r-filt ers	145	*	255.255.255.255	1	*	no	N/A

Attack flow:   1    *    *     192.168.100.34  *     no fragments

        Triggering rate: 11.97  Threshold: 10.00

        Policy: other_protocols/any/analysis/pkts/protocol

... ... ...

admin@GUARD-conf-zone-scannet#

The sample screen indicates that the Guard produced Dynamic filters (See Chapter 9, "Advanced Filter Procedures," for further details on Dynamic Filters). The displayed filter handles protocol (Proto) number one 1 type traffic, which is ICMP typed traffic. In this case the Guard Policy blocks the filters' traffic from flowing to the zone.

Spoofed ?

This is the stage in which the user further analyses the TCP traffic to determine whether it is spoofed attack, a non-spoofed attack or a zombie attack.

Spoofed

Initial indication for a spoofed attack is derived from the Replied counter when issuing the show counters details command. When the Replied counter displays a relatively high number of packets, this indicates that there is a spoofed attack in progress.

Further indication is derived from viewing the Dynamic Filter that show whether and which protection measures the Guard took to face the attack.

To view the Dynamic filter the Guard produced, issue the show dynamic-filters command.

To view the Dynamic filter, perform the following:

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

admin@GUARD-conf-zone-<zone-name># show dynamic-filters details

2. Choose ENTER. The following sample screen appears:

**** DYNAMIC FILTERS ****

ID	Action	Exp Time	Source IP	Source Mask	Proto	DPort	Frg	RxRate (pps)
6	to-user- filters	595	*	255.255.255.255	6	*	no	N/A

Attack flow:   6    *    *     192.168.100.34  80     no fragments

        Triggering rate: 45000.00       Threshold: 30.00

        Policy: tcp_outgoing/any/analysis/syns/dst_ip

The screen columns are:

•ID—This column indicates the filter identification number.

•Action—This column indicates the action the Dynamic filter assumes.

•ExpTime—This column indicates the amount of time for filter activation. After that the filter might be erased according to a set of criteria (see the "Advanced Dynamic Filters Configuration" section in Chapter 9, "Advanced Filter Procedures," for details).

•Source IP—This column indicates the source IP address of the mitigated attack stream. The source IP may be non-specific. i.e. "*" which means the value is undetermined or that the filter handles several traffic flows from the same IP address.

•Source Mask—This column indicates the source mask of the mitigated attack stream. The source mask may be non-specific. i.e. "*" which means the value is undetermined that the filter handles several traffic flows from the same source mask.

•Proto—This column indicates the protocol well-known number of the mitigated attack. An `*' would indicate a non-specific protocol attack.

•DPort—This column indicates the filter-protected destination port. An `*' would indicate a non-specific destination port.

•Frg—This column indicates whether the User filter protects against fragmented traffic: `yes' indicates a protection against fragmented traffic, "no" indicates protection against non-fragmented traffic, and "any" indicates protection against both fragmented and non-fragmented traffic.

•RxRate(pps)—This column indicates the current traffic rate measured for this Dynamic filter in packets per second (pps).

•Attack flow—The flow of the attack that was mitigated. Note that the mitigated attack flow, displayed in the Dynamic Filters table, could be of a wider range than the attack flow. For example, a non-spoofed attack on port 80 will block all TCP traffic from the originating source IP and not only port 80. The attack flow parameters consist of the following accordingly:

Protocol—The protocol well-known number of the attack flow.

Source IP—The source IP of the attack flow.

Source Port—The source port of the attack flow.

Destination IP—The destination IP of the attack flow.

Destination Port—The destination port of the attack flow.

Fragments— Indicates whether the attack flow contains fragmented traffic: `fragments' indicates fragmented traffic, `no fragments' indicates non-fragmented traffic, and "any" indicates both fragmented and non-fragmented traffic.

Triggering Rate —The attack flow traffic rate that violated a policy threshold.

Threshold—The policy threshold that was violated by the attack flow.

Policy—Indicates the policy that produced the specified Dynamic filter.

A value of "*" for any of the parameters indicates one of the following:

•The value is undetermined.

•More than one value was measured for the attack flow parameter.

The above sample screen indicates the following:

•The Guard Dynamic filter directs the traffic to the User-filter anti-spoofing mechanism. This indicates an active protection against a spoofed attack.

•The fact that no drop-action dynamic filter was produced also points out that this is a spoofed attack.

HTTP Zombie Attack

A zombie attack is a type of attack that uses unaware participant machines to launch a DDoS attack. The attacker first spreads a Trojan to unsuspecting users that are not the final target, and may later instruct the Trojan to perform "legitimate" (non-spoofed) connections to the zone. The Guard activates an innovative mechanism to distinguish between packets originated by zombies and legitimate traffic.

Initial indication for an attack is derived when issuing the show counters details command. Having the Received counter higher than the Forwarded counter (and a high value of the Malicious counter) indicate that an attack is in progress. When the Replied counter displays a relatively high number of packets, this indicates that there is a spoofed attack or a zombie attack in progress.

admin@GUARD-conf-zone-scannet# show counters details

                    Packets          KBits

Legitimate traffic: 255123           130011

Malicious  traffic: 102531           73632

Details:

Received   traffic: 357989           205523

Forwarded  traffic: 255123           130011

Dropped    traffic: 25710            12855

Replied    traffic: 77156            62656

Invalid    zone   : 0                0

Further indication is derived from viewing the Dynamic Filter that show whether, and which, protection measures the Guard took to face the attack.

To view the Dynamic filter the Guard produced, issue the show dynamic-filters command.

To view the Dynamic filter, perform the following:

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

admin@GUARD-conf-zone-<zone-name># show dynamic-filters details

2. Choose ENTER. The following sample screen appears:

**** DYNAMIC FILTERS ****

ID	Action	Exp Time	Source IP	Source Mask	Proto	DPort	Frg	RxRate (pps)
1	to-user- filters	478	*	255.255.255.255	6	*	no	N/A

Attack flow:   6    *    * 192.168.100.34  80 no fragments

    Triggering rate: 50.00  Threshold: 50.00

   Policy: tcp_connections/any/analysis/in_nodata_conns/global

ID	Action	Exp Time	Source IP	Source Mask	Proto	DPort	Frg	RxRate (pps)
2	redirect /zombie	498	*	255.255.255.255	6	*	no	N/A

Attack flow:   6   *    *     192.168.100.34  80 no fragments

    Triggering rate: 112.00 Threshold: 100.00

       Policy: tcp_connections/any/basic/num_sources/global

The previous sample screen indicates the following:

•The Guard Dynamic filter (ID=1) directs the traffic to the User-filter. The policy that created the Dynamic filter indicates that anomalies of TCP connections with no data were identified.

•The Guard Dynamic filter (ID=2) directs the traffic to a filter with the action of redirect/zombie . The policy that created the Dynamic filter indicates that a large number of non-spoofed TCP source IPs, destined to the zone, has been identified. This could indicate that a zombie attack is in progress. The Anti-zombie protection mechanism is activated.

The user may view the list of attacking zombies.

To view the list of zombies, perform the following:

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

admin@GUARD-conf-zone-<zone-name># show zombies

From the Global or Configuration command group levels, type the following:

admin@GUARD-conf# show zone <zone-name> zombies

2. Choose ENTER. The following sample screen is displayed:

admin@GUARD-conf-zone-scannet#show zombies

 IP              Start Time      Duration   #Requests

 192.168.100.100 Dec 03 14:57:04 00:01:36   5

 192.168.100.101 Dec 03 14:57:04 00:01:36   22

 192.168.100.102 Dec 03 14:57:04 00:01:36   15

 192.168.100.103 Dec 03 14:57:06 00:01:34   31

 192.168.100.104 Dec 03 14:57:04 00:01:36   7

... ... ..

The screen columns represent the following:

•IP—The zombie IP address

•Start Time—The date and time the zombie connection was initially identified

•Duration—The duration of the zombie attack

•#Requests—The number of HTTP get requests sent by the zombie

Non-spoofed

After issuing the show counters details command, the Guard displays the following sample screen indicating a non-spoofed attack:

admin@GUARD-conf-zone-scannet#show counters details

                    Packets          KBits

Legitimate traffic: 271830           140008

Malicious  traffic: 2876             1438

Received   traffic: 274783           141502

Forwarded  traffic: 271830           140008

Dropped    traffic: 2875             1437

Replied    traffic: 78               55

Invalid    zone   : 0                0

The sample screen indicates that the number of replied packets that originate from the action of the Guard anti-spoofing mechanisms is relatively (compared with the received packets number) very low - This indicates a non-spoofed attack.

To view the Dynamic filter the Guard produced, issue the show dynamic-filters command (see the "Spoofed ?" section on how to issue this command).

The following sample screen appears:

admin@GUARD-conf-zone-scannet# show dynamic-filters

**** DYNAMIC FILTERS ****

ID	Action	Exp Time	Source IP	Source Mask	Proto	DPort	Frg	RxRate (pps)
1	to-user- filters	547	*	255.255.255.255	6	80	no	N/A
2	strong	588	192.168 .100.40	255.255.255.255	6	*	no	9
3	drop	599	192.168 .100.40	255.255.255.255	6	*	no	N/A

The sample screen indicates that the Guard produced three Dynamic filters. These consist of the first filter directing the TCP traffic flow to the User defined filters (Action = to-user-filters), the second directing the TCP traffic flow to the Guard Strong protection module (Action = strong), and the third directing the TCP traffic flow to the Guard Drop protection module (Action = drop). The transfer of the protection modules from the User filters to the Strong and finally to the Drop indicates that the Guard's anti-spoofing mechanisms have not identified the attack as a spoofed attack and consequently the malicious traffic is dropped. This indicates a non-spoofed attack.