HP-UX Host Intrusion Detection System Version 4.3 administrator guide
Table Of Contents
- HP-UX Host Intrusion Detection System Version 4.3 administrator guide
- Table of Contents
- About This Document
- 1 Introduction
- 2 Configuring HP-UX HIDS
- 3 Getting Started with HP-UX HIDS
- 4 Using the System Manager Screen
- Starting the HP-UX HIDS System Manager
- Stopping the HP-UX HIDS System Manager
- System Manager Components
- Starting HP-UX HIDS Agents
- Getting the Status of Agent Hosts
- Resynchronizing Agent Hosts
- Activating Schedules on Agent Hosts
- Stopping Schedules on Agent Hosts
- Halting HP-UX HIDS Agents
- Accessing Other Screens
- 5 Using the Schedule Manager Screen
- The Schedule Manager
- Configuring Surveillance Schedules
- Configuring Surveillance Groups
- Configuring Detection Templates
- Setting Surveillance Schedule Timetables
- Configuring Alert Aggregation
- Configuring Monitor Failed Attempts
- Configuring Duplicate Alert Suppression
- Viewing Surveillance Schedule Details
- Predefined Surveillance Schedules and Groups
- 6 Using the Host Manager Screen
- 7 Using the Network Node Screen
- 8 Using the Preferences Screen
- A Templates and Alerts
- Alert Summary
- UNIX Regular Expressions
- Limitations
- Template Property Types
- Buffer Overflow Template
- Race Condition Template
- Modification of files/directories Template
- Changes to Log File Template
- Creation and Modification of setuid/setgid File Template
- Creation of World-Writable File Template
- Modification of Another User’s File Template
- Login/Logout Template
- Repeated Failed Logins Template
- Repeated Failed su Commands Template
- Log File Monitoring Template
- B Automated Response for Alerts
- C Tuning Schedules and Generating Alert Reports
- D The Agent Configuration File
- E The Surveillance Schedule Text File
- F Error Messages
- G Troubleshooting
- Troubleshooting
- Agent and System Manager cannot communicate with each other
- Agent complains that idds has not been enabled, yet lsdev shows /dev/idds is present
- Agent does not start on system boot
- Agent halts abnormally, leaving ids_* files and message queues
- Agent host appears to hang and/or you see message disk full
- Agent needs further troubleshooting
- Agent does not start after installation
- Agents appear to be stuck in polling status
- Agent displays error if hostname to IP mapping is not registered in name service
- Aggregated alerts targets or details field are truncated and the same aggregated alert has several entries logged in the IDS_ALERTFILE
- Alert date/time sort seems inconsistent
- Alerts are not being displayed in the alert browser
- Buffer overflow triggers false positives
- Duplicate alerts appear in System Manager
- Getting several aggregated alerts for the same process
- GUI runs out of memory after receiving around 19,000 alerts
- The idsadmin Command needs installed agent certificates
- The idsadmin Command notifies of bad certificate when pinging a remote agent
- IDS_checkInstall fails with a kmtune error
- IDS_genAdminKeys or IDS_genAgentCerts does not complete successfully
- IDS_genAdminKeys or idsgui quits early
- Large files in /var/opt/ids
- Log files are filling up
- No Agent Available
- Normal operation of an application generates heavy volume of alerts
- Reflection X rlogin produces multiple login and logout alerts
- Schedule Manager timetable screen appears to hang
- SSH does not perform a clean exit after idsagent is started
- System Manager appears to hang
- System Manager does not let you save files to specific directories
- System Manager does not start after idsgui is started
- System Manager starts with no borders or title bar in X client programs on Windows
- System Manager times out on agent functions such as Activate and Status Poll
- UNKNOWN program and arguments in certain alert messages
- Using HP-UX HIDS with IPFilter and SecureShell
- Unable to Generate Administrator Keys and Agent Certificates on PA–RISC 1.1 Systems
- Troubleshooting
- H HP Software License

“X” for exact match. This means that the filter is a regular expression that matches one
and only one file pathname.
—
— “R” for regular expression match. This means that regular expression wildcard characters
are used to match one or more file pathnames.
— “” (empty string) for no filter. This mean that no filter will be generated for this alert.
• <Attacked File> is the absolute name of the file under attack.
• <Action> is the action (event) for which the alert was generated.
• <User> is the euid:egid:ruid:rgid of the user who generated the alert.
• <Severity> is the severity level of the alert. It can be 1 (critical), 2 (severe), or 3 (moderate).
• <Date> is the date when the <Action> triggered the alert.
• <Count> is the number of duplicate alerts of this type.
• [File Filter] is an optional filter generated for pathname_X template property.
• [Program Filter] is an optional filter generated for program_X template property.
• [Filter Comment] can be set to a comment explaining the choice of filter. If there is no filter,
it explains the reason for not having a filter.
• <Template Code> is for internal use and must not be modified.
Section Related to Aggregated Alerts
The summary for aggregated alerts contains the following fields:
<Ancestor> <Number of alerts> <user> <highest
severity> <date> <count>
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:
<attacker> <attacked> <action> <severity> <template>
<date> <count>
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.
182 Tuning Schedules and Generating Alert Reports