HP-UX Host Intrusion Detection System Version 4.1 Administrator's Guide

Where:

• <Ancestor> is the top-level program that caused the alert in a multi-process alert.

• <Number of alerts> is the number of alerts aggregated in the meta alert.

• <user> is the user who generated the alert.

• <highest severity> is the highest severity among all the alerts in the meta

alert.

• <date> is the time when the first alert in the meta alert was generated.

• <count> is the number of occurrences of the same meta alert.

NOTE: No filters are generated for aggregated alerts, and they cannot be filtered

using the idsadmin tune command.

Section Related to System Alerts

The summary of system alerts contains the following fields:

Where:

• <attacker> is the hostname or the IP address of the remote host from which the

alert was generated (in the case of a login alert). In the case of a logout alert, it is

the terminal from which the user logged out. In case of a successful su attack,

failed login, or failed su attack, it is the name of the user who caused the alert.

• <attacked> is the hostname or IP address of the agent under attack.

• <action> is the action for which the alert was generated.

• <severity> is the severity level of the alert. It can be 1 (critical), 2 (severe), or 3

(moderate).

• <template> is the name of the template.

• <date> is the time at which the first such alert was detected.

• <count> is the number of duplicate alerts.

NOTE: No filters are generated for system alerts, and they cannot be filtered using

the idsadmin tune command.

NOTE: Duplicate failed login and su attempts can be suppressed using the

max_failed_[login,su], warning_interval, and fail_interval template

properties.

Using the tune Command

The following examples show different ways of using the tune command to tune your

schedules:

224 Tuning Schedules and Generating Alert Reports