HP-UX Host Intrusion Detection System Version 4.4 Administrator Guide (5900-1634, April 2011)

Under these conditions, HIDS may only have access to the path name used to invoke the
program, and the path name used can either be a relative path name or not be fully resolved.
It can contain symbolic links.
For example, a program with full path name /usr/bin/program can be invoked as program
or as ../bin/program, or as /bin/program, where /bin is a symbolic link to /usr/
bin. Under the conditions previously stated, alert aggregation cannot happen as expected
if the regular expression ^/usr/bin/program$ is specified in the aggregation tuple instead
of program.
• When the Alert Aggregation option box is deselected in the GUI Schedule Manager Alert
Aggregation tab, the Real Time Alerts option box is disabled and is automatically selected to
indicate that real-time alerts will be issued.
• Aggregated alerts, such as those generated when installing or removing software using SD,
can potentially be very large (many Kbytes in size). You may notice that aggregated alerts in
the IDS_ALERTFILE are divided into portions and sent to response programs in portions.
The first portion’s code field has a value of 11 and the subsequent portions will have a code
field value of 12 (see /opt/ids/share/examples/ids_alertResponse.c). You will
also notice that alert targets and detail fields are truncated for these aggregated alert portions.
The kernel tunables (msgmax and msgmnb) govern the size of the alerts sent by the idscor
process to the idsagent process, using IPC message queues. To minimize the segmentation
of large aggregated alerts, you can increase the values of the msgmax and msgmnb kernel
tunables.
• For large aggregated alerts, only the first portion of the aggregated alert is displayed by the
GUI network node. You must refer to the alert log file of the agent to see the complete portion
of the aggregated alert.
Configuring Monitor Failed Attempts
Monitor Failed Attempts is a surveillance schedule feature that, when enabled, alerts the
administrator when there are failed attempts to create, delete, or modify critical files, an indication
that there might be an intrusion or system misuse is in progress. The monitoring of failed attempts,
when enabled, is only performed for the Modification of files/directories template,
the Changes to Log File template, and Modification of Another User’s File
template.
As an example, if the permissions on the file/etc/passwd only allows read permission for users,
group, and others, and an attacker tries to open the /etc/passwd file with write permission, the
open will fail. If the Monitor Failed Attempts feature is enabled, an alert is issued.
The Monitor Failed Attempts feature is disabled by default for all newly created and pre-defined
surveillance schedules. It can be configured either by using the GUI Schedule Manager window,
or by editing a schedule in text format. For more information on the schedule in text format, see
“Surveillance Schedule Text File” (page 193). The feature can also be enabled by setting
MONITOR_FAILED_ATTEMPTS parameter in ids.cf configuration file (see “Kernel Audit Data
DSP” (page 189)). The ids.cf configuration file can be used to override the
monitor_failed_attempts global property specified in the surveillance schedule.
To configure and enable the Monitor Failed Attempts feature, follow these steps:
70 Using the Schedule Manager Screen