Worm viruses are automated, self-propagating, intrusion agents that make copies of themselves and then facilitate their spread. Worm viruses attack a vulnerable host, infect it, and then use it as a base to attack other vulnerable hosts. They search for other hosts by using a form of network inspection, typically a scan, and then propagate to the next target. A scanning worm virus locates vulnerable hosts by generating a list of IP addresses to probe, and then contacts the hosts. Code Red worm, Sasser worm, Blaster worm, and the Slammer worm are examples of worms that spread in this manner.

Anomaly detection identifies worm-infected hosts by their behavior as a scanner. To spread, a worm virus must find new hosts. It finds them by scanning the Internet using TCP, UDP, and other protocols to generate unsuccessful attempts to access different destination IP addresses. A scanner is defined as a source IP address that generates events on the same destination port (in TCP and UDP) for too many destination IP addresses.

The events that are important for TCP are non-established connections, such as a SYN packet that does not have its SYN-ACK response for a given amount of time. A worm-infected host that scans using TCP generates non-established connections on the same destination port for an anomalous number of IP addresses.

The events that are important for UDP are unidirectional connections, such as a UDP connection where all packets are going in only one direction. A worm-infected host that scans using UDP generates UDP packets but does not receive UDP packets on the same IP address within a time-out period on the same destination port for multiple destination IP addresses.

The events that are important for other protocols, such as ICMP (protocol number 1), are from a source IP address to many different destination IP addresses, that is, packets that are received in only one direction.

Caution

If a worm virus has a list of IP addresses it should infect and does not have to use scanning to spread itself (for example, it uses passive mapping—listening to the network as opposed to active scanning), it will not be detected by anomaly detection worm policies. Worm viruses that receive a mailing list from probing files within the infected host and email this list will not be detected, because no Layer 3 or Layer 4 anomaly is generated.

Anomaly detection initially conducts a “peacetime” learning process when the most normal state of the network is reflected. Anomaly detection then derives a set of policy thresholds that best fit the normal network. This is done in two phases: an initial learning mode phase, followed by the ongoing operational detect mode phase.

Anomaly detection has the following modes:

• Learning accept mode (initial setup)

Although anomaly detection is in detect mode by default, it conducts an initial learning accept mode for the default period of 24 hours. We assume that during this phase no attack is being carried out. Anomaly detection creates an initial baseline, known as a knowledge base, of the network traffic. The default interval value for periodic schedules is 24 hours and the default action is rotate, meaning that a new knowledge base is saved and loaded, and then replaces the initial knowledge base after 24 hours.

Keep the following in mind:

• Anomaly detection does not detect attacks when working with the initial knowledge base, which is empty. After the default of 24 hours, a knowledge base is saved and loaded and now anomaly detection also detects attacks.

• Depending on your network complexity, you may want to have anomaly detection in learning accept mode for longer than the default 24 hours. You configure the mode in the Virtual Sensors policy; see Defining A Virtual Sensor. After your learning period has finished, edit the virtual sensor and change the mode to Detect.

• Detect mode

For ongoing operation, the sensor should remain in detect mode. This is for 24 hours a day, 7 days a week. Once a knowledge base is created and replaces the initial knowledge base, anomaly detection detects attacks based on it. It looks at the network traffic flows that violate thresholds in the knowledge base and sends alerts. As anomaly detection looks for anomalies, it also records gradual changes to the knowledge base that do not violate the thresholds and thus creates a new knowledge base. The new knowledge base is periodically saved and takes the place of the old one thus maintaining an up-to-date knowledge base.

• Inactive mode

You can turn anomaly detection off by putting it in inactive mode. Under certain circumstances, anomaly detection should be in inactive mode, for example, if the sensor is running in an asymmetric environment. Because anomaly detection assumes it gets traffic from both directions, if the sensor is configured to see only one direction of traffic, anomaly detection identifies all traffic as having incomplete connections, that is, as scanners, and sends alerts for all traffic flows.

The following example summarizes the default anomaly detection configuration. If you add a virtual sensor at 11:00 pm and do not change the default anomaly detection configuration, anomaly detection begins working with the initial knowledge base and only performs learning. Although it is in detect mode, it cannot detect attacks until it has gathered information for 24 hours and replaced the initial knowledge base. At the first start time (10:00 am by default), and the first interval (24 hours by default), the learning results are saved to a new knowledge base and this knowledge base is loaded and replaces the initial knowledge base. Because the anomaly detection is in detect mode by default, now that anomaly detection has a new knowledge base, the anomaly detection begins to detect attacks.

By subdividing the network into zones, you can achieve a lower false negative rate. A zone is a set of destination IP addresses. There are three zones, each with its own thresholds: internal, illegal, and external.

The external zone is the default zone with the default Internet range of 0.0.0.0-255.255.255.255. By default, the internal and illegal zones contain no IP addresses. Packets that do not match the set of IP addresses in the internal or illegal zone are handled by the external zone.

We recommend that you configure the internal zone with the IP address range of your internal network. If you configure it in this way, the internal zone is all the traffic that comes to your IP address range, and the external zone is all the traffic that goes to the Internet.

You can configure the illegal zone with IP address ranges that should never be seen in normal traffic, for example, unallocated IP addresses or part of your internal IP address range that is unoccupied. An illegal zone can be very helpful for accurate detection, because we do not expect any legal traffic to reach this zone. This allows very low thresholds, which in turn can lead to very quick worm virus detection.

Anomaly detection assumes that it gets traffic from both directions. If the sensor is configured to see only one direction of traffic, you should turn off anomaly detection. Otherwise, when anomaly detection is running in an asymmetric environment, it identifies all traffic as having incomplete connections, that is, as scanners, and sends alerts for all traffic flows.

You turn off anomaly detection in the Virtual Sensors policy. Edit the virtual sensor for which you are disabling anomaly detection, and change the Anomaly Detection Mode to Inactive. For information on editing virtual sensors, see Editing Policies for a Virtual Sensor.

The Traffic Anomaly engine contains nine anomaly detection signatures covering three protocols (TCP, UDP, and other). Each signature has two subsignatures, one for the scanner and the other for the worm-infected host (or a scanner under worm attack). When anomaly detection discovers an anomaly, it triggers an alert for these signatures. All anomaly detection signatures are enabled by default and the alert severity for each one is set to high.

When a scanner is detected but no histogram anomaly occurred, the scanner signature fires for that attacker (scanner) IP address. If the histogram signature is triggered, the attacker addresses that are doing the scanning each trigger the worm signature (instead of the scanner signature). The alert details state which threshold is being used for the worm detection now that the histogram has been triggered. From that point on, all scanners are detected as worm-infected hosts.

The following anomaly detection event actions are possible:

• Produce alert—Writes the event to the Event Store.

• Deny attacker inline—(Inline only) Does not transmit this packet and future packets originating from the attacker address for a specified period of time.

• Log attacker packets—Starts IP logging for packets that contain the attacker address.

• Deny attacker service pair inline—Blocks the source IP address and the destination port.

• Request SNMP trap—Sends a trap notification to an SNMP trap destination. To use this action, you must configure SNMP trap hosts as described in Configuring SNMP.

• Request block host—Sends a request to ARC to block this host (the attacker). To use this action, you must configure blocking devices as described in Configuring IPS Blocking and Rate Limiting.

You can add actions to the signatures either directly, in the Signatures policy, or to events generated by the signatures based on risk rating in the Event Actions Overrides policy.

The following table lists the anomaly detection worm signatures.