30.3 Host Intrusion Detection System (HIDS)

Host Intrusion Detection System (HIDS) was formerly known as Intrusion Detection System/9000 (IDS/9000) and/or HP Praesidium Intrusion Detection System/9000. The older IDS/9000 comes standard with HP-UX 11i Operating Environments but is not installed by default. Prior to HP-UX 11i, HIDS and IDS/9000 were separate purchasable items. The current release of HIDS (2.2) has no additional operational features over IDS/9000 but has updated some features as well as provided some bug fixes. In fact, when you download and install HIDS, you will see that the software products and filesets are still called IDS. Forgive me if I sometimes refer to HIDS as IDS.

The idea behind HIDS is to provide host-level intrusion detection whereby we detect the illegal and/or improper use of computer resources, and that's all! We must realize that this is basically the limit of what HIDS can do. On its own, HIDS will not make your system any more or less secure; if your system has gaping holes in security, those holes will still be there after you install and configure HIDS. It is important that we perform the minimum security requirements mentioned in Chapter 29 and seriously consider running penetration tests on all our systems. Once we have achieved what we would regard as a reasonable level of security, HIDS will inform us of any untoward activity.

A feature I like about HIDS is that it was designed with a distributed network of machines in mind. In such a configuration, it would be tedious to log in to each machine and monitor individual alert logs. HIDS gets around this by configuring a central node as the HIDS Server. This could be a central management station used by IT/Security staff. On the machines we are monitoring, the HIDS Clients send alerts to the HIDS Server that are displayed and managed via a reasonably intuitive GUI interface.

A fundamental benefit behind using HIDS is the notion that HP has spent a considerable time working out the main avenues of attack that an unauthorized user would use to interfere or gain unauthorized privileges on an HP-UX system. These are affectionately known as Detection Templates. The current list of Detection Templates includes:

Modification of files and directories
Changes to logfiles
Creation of set UID files
Creation of world writeable files
Repeated failed logins
Repeated failed su attempts
Race condition attacks
Buffer overflow attacks
Modification of another user's files
Monitor for the start of interactive sessions
Monitor logins and logouts

Within each template, we can customize which files and directories we want to monitor. Initially, we may use the templates as is. In my experience, this produces lots of alerts. Customizing the templates to your own use, i.e., to include particular application files and directories can take some considerable time. Once configured, HIDS will continuously monitor and report alerts back to the HIDS Server. When we look at the templates listed above, we will probably want to utilize a number of these templates. When we group templates together, this is known as a Surveillance Group. Allied with a Surveillance Group will be a Surveillance Schedule. As the name suggests, a Surveillance Schedule tells HIDS when to activate the monitoring of resources listed in the Surveillance Group. We can then download a Surveillance Schedule to an HIDS Client. Once activated, the HIDS Client will be continuously monitored within the parameters of the Surveillance Schedule. The alerts produced are sent back to the HIDS Server using secure communications; the HIDS Server creates private/public keys that are used by the clients to encrypt their alert reports . It's a good idea to ensure that an intruder can't see the transmission of alerts over the network. To summarize, these activities are involved:

Install HIDS on the HIDS Server and all HIDS Clients.
Create the private/public keys on the HIDS Server.
Import the public keys on each HIDS Client.
Start the HIDS Agent Software.
Create a Surveillance Schedule that will reference at least one Surveillance Group.
Create a Surveillance Group containing the relevant Detection Templates.
1. HP provides some preconfigured Surveillance Groups that you can use.
2. You may want to customize which files and directories the Detection Templates monitor.
Select the hosts (HIDS Client) to be monitored.
Download and activate a Surveillance Schedule to the relevant HIDS Clients.
Monitor alerts on the HIDS Server.
Create Response Programs on the HIDS Clients to react to alerts locally (optional).

Let's go through these tasks one by one.

30.3.1 Install HIDS on the HIDS Server and all HIDS Clients

As mentioned previously, HIDS was formerly known as IDS/9000, which came standard with HP-UX 11i (on the Core OS CD/DVD). If you don't have IDS/9000, HIDS is available free of charge from http://software.hp.com - Security and Manageability. We need to install HIDS as well as Java 1.3.1.01 or greater onto the HIDS Server. (B9789AA is free but not installed with HP-UX 11i, or it can be downloaded free from http://www.hp.com/products1/unix/java/.) There is a kernel-auditing component (nothing to do with system/Trusted System auditing) to HIDS; hence, it requires a reboot to install it. On the HIDS Client, we only need to install the HIDS software; Java is not required:

 root@hpeos004[.root]  swlist -l fileset -s /software/11i-PA/HIDS -a is_reboot a   revision  # Initializing... # Contacting target "hpeos004"... # # Target:  hpeos004:/software/11i-PA/HIDS # # IDS                                   B.02.02.16   IDS.IDS-ADM-RUN                       B.02.02.16     false   IDS.IDS-ADM-SHLIB                     B.02.02.16     false   IDS.IDS-AGT-KRN                       B.02.02.16     true   IDS.IDS-AGT-RUN                       B.02.02.16     false   IDS.IDS-AGT-SHLIB                     B.02.02.16     false   IDS.IDS-ENG-A-MAN                     B.02.02.16     false # Java2-RTE13_base                      1.3.1.02.01   Java2-RTE13_base.JAVA2-JRE-BASE       1.3.1.02.01    false # Java2-RTE13_doc                       1.3.1.02.01   Java2-RTE13_doc.JAVA2-JRE-DOC         1.3.1.02.01    false # Java2-RTE13_perf                      1.3.1.02.01   Java2-RTE13_perf.JAVA2-JRE            1.3.1.02.01    false root@hpeos004[.root]

30.3.2 Create the private/public keys on the HIDS Server

We must configure HIDS from an ids account that should have been created as part of the installation process:

 root@hpeos004[.root]  grep ids /etc/passwd /etc/group  /etc/passwd:ids:*:112:104:HP-UX Host IDS Administrator:/home/ids:/sbin/sh /etc/group:ids::104: root@hpeos004[.root]

Before we create the public/private keys, we should consider whether our HIDS Server and/or IDS Clients are multi-homed . If our HIDS Servers and/or Clients are multi- homed machines, we specify which IP address is to be used to identify the HIDS Server. This may need to be achieved on both the HIDS Server and HIDS Client.

30.3.2.1 A MULTI-HOMED HIDS SERVER

You need to decide which interface is going to listen to requests from HIDS Clients. Your HIDS Server cannot listen to IDS Clients on separate physical networks. In the HIDS GUI (/opt/ids/bin/idsgui ), we need to configure which IP address (and, hence, the interface we will use) the IDS Server will listen for HIDS Clients:

 root@hpeos004[.root]  netstat -in  Name    Mtu  Network         Address         Ipkts   Ierrs Opkts   Oerrs Coll lan1    1500 192.168.0.64    192.168.0.66    11335   0     11656   0     1030 lan0    1500 192.168.0.32    192.168.0.35    1589    0     1605    0     2 lo0     4136 127.0.0.0       127.0.0.1       1793    0     1793    0     0 root@hpeos004[.root]

As you can see, this machine is multi-homed. Being my HIDS Sever, I will need to update my idsgui script:

 $  id  uid=112(ids) gid=104(ids) $ $  hostname  hpeos004 $ $  ll /opt/ids/bin/idsgui  -r-x------   1 ids        ids       7479 May  7 23:02 /opt/ids/bin/idsgui $ $  chmod u+w /opt/ids/bin/idsgui  $ $  vi /opt/ids/bin/idsgui  #!/usr/bin/sh ######################################################################### ##################### # GUI CONFIGURATION # ##################### # Host name or IP address (in dot notation) of interface to listen for # connections. If not set, the default value is the local host name.  INTERFACE=192.168.0.35  ... $  chmod u=rx /opt/ids/bin/idsgui  $

I need to ensure that all my HIDS Clients are using this address:

 $  id  uid=105(ids) gid=104(ids) $  hostname  hpeos002 $ $  ll /etc/opt/ids/ids.cf  -rw-------   1 ids        ids          17232 Feb  8  2003 /etc/opt/ids/ids.cf $  vi /etc/opt/ids/ids.cf  ... [RemoteSA] REMOTEHOST             IDS_importCert.will.replace.this ... $

As you can see from the comments in the ids.cf file, the import of the public keys should update the REMOTEHOST variable; we will check this after we have imported the public keys.

30.3.2.2 A MULTI-HOMED HIDS CLIENT

An HIDS Client will receive commands (a Surveillance Schedule) from the HIDS Server. We need to tell the HIDS Client on which interface those commands will be received. This address should match the IP address that the HIDS Server uses to resolve the hostname for this machine.

 root@hpeos003[.root]  netstat -in  Name      Mtu  Network         Address         Ipkts   Ierrs Opkts   Oerrs Coll lan1      1500 192.168.0.64    192.168.0.65    661     0     501     0     0 lan0      1500 192.168.0.32    192.168.0.33    2222    0     1944    0     4 lo0       4136 127.0.0.0       127.0.0.1       1658    0     1658    0     0 root@hpeos003[.root]

As you can see, we have two interfaces on this machine. We will configure the ids.cf file to ensure that we listen on the appropriate interface:

 $  id  uid=107(ids) gid=105(ids) $ $  hostname  hpeos003 $ $  ll /etc/opt/ids/ids.cf  -rw-------   1 ids        ids      17232 Feb  8  2003 /etc/opt/ids/ids.cf $ $ $  vi /etc/opt/ids/ids.cf  ... # # This parameter is only needed if you are running HP-UX Host IDS on a # multi-homed system. It should be set to the name of the network # address that the HP-UX Host IDS GUI will communicate to this agent # on. It can be either a hostname which resolves to a unique # IP address, or an IP address in dotted-decimal notation. # If this parameter is omitted, idsagent will not start execution # on a multi-homed system. #  IDS_LISTEN_IFACE                192.168.0.65  ... $

Now we can continue to create the public/private keys. At this time, it would be useful if we know all the HIDS Clients that are going to participate in this configuration. If we add more nodes later, we will need to repeat this step including the new nodes as appropriate. The import of the public keys needs to be accomplished only on the new nodes. We will use the /opt/ids/bin/IDS_genAdminKeys command to create the public/private keys. We run this command as the ids user on the IDS Server:

 $  id  uid=112(ids) gid=104(ids) $  hostname  hpeos004 $  /opt/ids/bin/IDS_genAdminKeys  ==> Be sure to run this script on the IDS Administration host. Generating a certificate request for IDS Root CA... Generating a self-signed certificate for IDS Root CA... Generating a certificate for the HP-UX Host IDS System Manager... Generating cert signing request for HP-UX Host IDS System Manager... Signing the HP-UX Host IDS System Manager certificate request... Importing IDS Root CA certificate... Importing the HP-UX Host IDS System Manager certificate... ************************************************************ * Successfully created certificates for IDS Root CA and for * the HP-UX Host IDS System Manager. * Certificate public keys are valid for 700 days and are * 1024 bits in size. * * Now you need to create keys for each of the hosts on which * the Agent software is installed by running the script * 'IDS_genAgentCerts'. ************************************************************ $

We can now create certificates for each of the HIDS Clients using the IDS_genAgentCerts as mentioned above:

 $  /opt/ids/bin/IDS_genAgentCerts  ==> Be sure to run this script on the IDS Administration host. Generate keys for which host?  hpeos001  Generating key pair and certificate request for IDS Agent on hpeos001.... Signing certificate for IDS Agent on hpeos001... Certificate package for IDS Agent on hpeos001 is /var/opt/ids/tmp/hpeos001.tar.Z Next hostname (^D to quit)?  hpeos002  Generating key pair and certificate request for IDS Agent on hpeos002.... Signing certificate for IDS Agent on hpeos002... Certificate package for IDS Agent on hpeos002 is /var/opt/ids/tmp/hpeos002.tar.Z Next hostname (^D to quit)?  hpeos003  Generating key pair and certificate request for IDS Agent on hpeos003.... Signing certificate for IDS Agent on hpeos003... Certificate package for IDS Agent on hpeos003 is /var/opt/ids/tmp/hpeos003.tar.Z Next hostname (^D to quit)? ************************************************************ * Successfully created agent certificates for the following * hosts: *       hpeos001 *       hpeos002 *       hpeos003 * * Certificate public keys are valid for 700 days and are * 1024 bits in size. * * They are stored in /var/opt/ids/tmp as hostname.tar.Z * * You should now transfer the bundles via a secure channel * to the IDS agent machines. * * On each agent you will need to run the IDS_importAgentKeys * script to finish the installation. ************************************************************ $

As you can see from the output above, I now have a filename of the form <hostname>.tar.Z that I need to securely transport to each host and then import the keys on that host.

30.3.3 Import the public keys on the HIDS Clients

We have our public keys stored in the file /var/opt/ids/tmp/<hostname>.tar.Z . We need to find a secure means of transporting these files to the relevant hosts. Do not use rcp or ftp ! I am going to use ssh , which I set up in the previous section. If you don't have a secure network connection, you may want to copy the files to removable media, e.g., DDS or DLT. If you use removable media, ensure that the media is either destroyed or completely erased afterward.

 root@hpeos004[tmp]  pwd  /var/opt/ids/tmp root@hpeos004[tmp] root@hpeos004[tmp]  for x in 1 2 3  >  do  >  ssh hpeos00$x mkdir $PWD  >  ssh hpeos00$x chmod 755 $PWD  >  ssh hpeos00$x chown ids:ids $PWD  >  scp -p hpeos00$x.tar.Z hpeos00$x:$PWD  >  ssh hpeos00$x chown ids:ids $PWD/hpeos00$x.tar.Z  >  done  hpeos001.tar.Z                                100% 3844     7.1MB/s   00:00 hpeos002.tar.Z                                100% 3872     8.9MB/s   00:00 hpeos003.tar.Z                                100% 3841     7.9MB/s   00:00 root@hpeos004[tmp]

Now I can import the public keys on each of the HIDS Clients:

 $  id  uid=107(ids) gid=105(ids) $  hostname  hpeos003 $  cd /var/opt/ids/tmp  $  ll  total 8 -rw-------   1 ids        ids           3841 Oct 15 12:05 hpeos003.tar.Z $ $  /opt/ids/bin/IDS_importAgentKeys hpeos003.tar.Z hpeos004  Extracting key pair and certificates... Modifying the configuration file /etc/opt/ids/ids.cf to use hpeos004 as the IDS Administration host... ************************************************************ * Keys for IDS Agent were imported successfully. * * You can now run the idsagent process on this machine and * control it from the HP-UX Host IDS System Manager. ************************************************************ $ $  grep REMOTEHOST /etc/opt/ids/ids.cf  REMOTEHOST             hpeos004 $

As you can see, with the IDS_importAgentKeys command I specify the filename containing the keys and the hostname/IP address of the HIDS Server. You can see from above that this process has updated my ids.cf . I have purposely used the hostname, as we will see when I attempt to start the IDS Agent software.

30.3.4 Start the HIDS Agent software

In the previous step, I used a hostname for my HIDS Server even though I know it is a multi-homed machine. I know this will cause a problem when I try to start the HIDS Agent software. Here's the output from my first attempt at starting the HIDS Agent software:

 root@hpeos003[.root]  /sbin/init.d/idsagent start  (c)Copyright 1983-2000 Hewlett-Packard Co.,  All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993  The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved.                            RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013.                            Hewlett-Packard Company                            3000 Hanover Street                            Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). idsagent daemon started root@hpeos003[.root] Wed Oct 15 14:08:13 2003: libcomm: pid=4282 thread_id=1: comm_init:   connect_host (hpeos004) resolves to more than one IP address. Do not     know which one to use.   idsagent: idsagent initialization failed. See /var/opt/ids/error.log for details. Exiting root@hpeos003[.root]

The isdagent startup script performs an su “ ids . As you can see from the highlighted (bold, underlined italics) output, the HIDS Agent has found multiple IP addresses for the HIDS Server identified by hostname hpeos004 . We need to ensure that we update the ids.cf file with the IP address that the IDS Server used in the idsgui script.

 root@hpeos003[.root]  vi /etc/opt/ids/ids.cf  ...  REMOTEHOST  192.168.0.35 ... root@hpeos003[.root]

Now we can start the HIDS Agent software:

 root@hpeos003[.root]  /sbin/init.d/idsagent start  (c)Copyright 1983-2000 Hewlett-Packard Co.,  All Rights Reserved. (c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California (c)Copyright 1980, 1984, 1986 Novell, Inc. (c)Copyright 1986-1992 Sun Microsystems, Inc. (c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology (c)Copyright 1989-1993  The Open Software Foundation, Inc. (c)Copyright 1986 Digital Equipment Corp. (c)Copyright 1990 Motorola, Inc. (c)Copyright 1990, 1991, 1992 Cornell University (c)Copyright 1989-1991 The University of Maryland (c)Copyright 1988 Carnegie Mellon University (c)Copyright 1991-2000 Mentat Inc. (c)Copyright 1996 Morning Star Technologies, Inc. (c)Copyright 1996 Progressive Systems, Inc. (c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved.                            RESTRICTED RIGHTS LEGEND Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause in DFARS 252.227-7013.                            Hewlett-Packard Company                            3000 Hanover Street                            Palo Alto, CA 94304 U.S.A. Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR 52.227-19(c)(1,2). idsagent daemon started root@hpeos003[.root]

This looks better.

30.3.5 Create a Surveillance Schedule that will reference at least one Surveillance Group

This is accomplished on the HIDS Server via the /opt/ids/bin/idsgui interface. We run the GUI as the ids user ensuring that our DISPLAY variable has been set accordingly . When you first run the GUI, you may be asked to accept a license agreement. It's probably a good idea to Accept .

It is going to be difficult to give you screenshots for all the screens I navigate. I will try to give you bullet points of the steps I perform. and include all the steps for creating a Surveillance Schedule and a Surveillance Group in the next step in the process. I wanted to separate the tasks in this checklist just to ensure that we understand the relationship between the various ideas in the HIDS software.

30.3.6 Create a Surveillance Group containing the relevant Detection Templates

We are going to create a new Surveillance Schedule ( CKSchedule ) that contains only one Surveillance Group (a new group called CKSurveyGroup ), which contains a collection of customized Detection Templates. Here is a screenshot and accompanying bullet points for creating a Surveillance Schedule containing a single Surveillance Group (see Figure 30-3).

From the main screen in the idsgui , select Edit Schedule Manager .
Under the Schedule Manager window, click New to create a new schedule. I called my schedule CKSchedule . You could use an existing schedule if you prefer. Once created, ensure that you highlight your new Surveillance Schedule .
Choose New under the Surveillance Group window to create a new Surveillance Group . I decided to create a new Surveillance Group called CKSurveyGroup .
Ensure that your Surveillance Group is the only one selected.
Select the Detection Template that you want to include in your Surveillance Group .
If you wish, you can Edit the properties of individual elements of each Detection Template you choose.
When you are finished, Save your changes.
We are now ready to define a Timetable of which days and times the Surveillance Schedule will run (see Figure 30-4).

Figure 30-4. Specify a Timetable for a Surveillance Schedule.
When you first go into the Timetable tab, the default is to run the Surveillance Schedule all time; the Criteria button on the left side will have Always on selected. I think this is a good idea, because you don't know when an intruder is going strike. In the figure above, I have selected to monitor my Surveillance Group at particular times. NOTE: This is for demonstration purposes only. If you exclude certain times, e.g., outside of normal business hours, you run the risk of not monitoring your system(s) at the times when intruders normally operate , i.e., outside of normal business hours.
When you have specified you Timetable , you Save your changes. You can now close the Schedule Manager by clicking File Close . This will take you back to the main idsgui screen.

Figure 30-3. Creating a Surveillance Schedule referencing a single Surveillance Group.

30.3.7 Select the hosts (HIDS Client) to be monitored

We should now be back at the idsgui main screen, and should be able to see our new Surveillance Schedule in the Schedules window on the left side of the screen. Before we can download the Surveillance Schedule to a group of machines, we need to select the IDS Clients we want to monitor. We do this via the Host Manager ; click Edit Host Manager . We should get a list of nodes for which we created public keys. If a particular host isn't listed, we can add the host by using the Add button. Ensure that the Agent is running on any missing nodes (see Figure 30-5).

Figure 30-5. Add IDS Clients using the Host Manager.

On returning to the idsgui main System Manager screen, all HIDS Clients should now be in an Available state. NOTE: One issue I have experienced is that if you are not running NTP between your machines, the Certificates created on your HIDS Server have a Valid From as well as an Expiry date. If one of your HIDS Clients is slightly behind with respect to system time, it may fail to negotiate a SSL Handshake because there are no valid Certificates available. You can check the status of Certificates with the /opt/ids/bin/IDS_check[AdminAgent]Cert commands. You can also check errors in /var/opt/ids/error.log .

We are now ready to download and activate our new Surveillance Schedule to our selected hosts.

30.3.8 Download and activate a Surveillance Schedule to the relevant HIDS Clients

We simply highlight the Surveillance Schedule, highlight all the nodes to which we want to download the Surveillance Schedule (use Shift + click to highlight multiple nodes) and then press the Activate button. The status will go from Available to Downloading to Running. You may start to see alerts being highlighted soon after activation (see Figure 30-6).

Figure 30-6. Activating a Surveillance Schedule.

30.3.9 Monitor alerts on the HIDS Server

Individual nodes maintain their alerts in the file /var/opt/ids/alert.log . They are transmitted back to the HIDS Sever where they are held in the directory /var/opt/ids/gui/logs :

 root@hpeos004[logs]  pwd  /var/opt/ids/gui/logs root@hpeos004[logs] root@hpeos004[logs]  ll  total 52 -rw-------   1 ids        ids          18049 Oct 15 17:41 Trace.log -rw-------   1 ids        ids           2848 Oct 15 17:41 hpeos001_alert.log -rw-------   1 ids        ids            626 Oct 15 17:26 hpeos001_error.log -rw-------   1 ids        ids            626 Oct 15 17:26 hpeos002_error.log -rw-------   1 ids        ids            155 Oct 15 17:39 hpeos003_alert.log -rw-------   1 ids        ids           1252 Oct 15 17:25 hpeos003_error.log root@hpeos004[logs]

We can view the alerts and errors just by double-clicking an individual host in the idsgui main System Manager screen (see Figure 30-7).

Figure 30-7. Viewing and managing alerts.

Highlighting individual alerts ( errors can be found under the Errors tab near the top of the screen) will display the content of the alert in the panel at the bottom of the screen. This will also mark that alert as seen . You can delete seen alerts simply by clicking the Delete button.

30.3.10 Create Response Programs on the HIDS Clients to react to alerts locally (optional)

A response program is a shell script or a program that resides in the /opt/ids/response directory. You may find some examples in there as well as programs allowing you to integrate HIDS with OpenView Vantage Point Operations:

 root@hpeos001[response] #  pwd  /opt/ids/response root@hpeos001[response] #  ll  total 34 -r-x------   1 ids        ids         16384 Jul 16 15:56 ids_alertResponse -r-x------   1 ids        ids           573 Aug 24  2001 send_alert_to_vpo.sh dr-x------   2 ids        ids            96 Sep 16 15:52 vpo root@hpeos001[response] #

Whenever an alert occurs, the response program is executed with a number of command line arguments (as shown in Table 30-1).

Table 30-1. Arguments Passed to Response Programs

Argument	Data Type	Name	Description
`argv[0]`	String	Program	Name of the executable.
`argv[1]`	Integer	Code	Code assigned to the detection template. Three digits with leading zeros, as in 005 and 027.
`argv[2]`	Integer	Version	Version of the detection template.
`argv[3]`	Integer	Severity	A number from `1` to `3` indicating the general severity of the alert as follows : Critical (1) : Can provide root access to an attacker. Severe (2) : Can compromise the operation of the system, overwrite or delete files, attempt to gain privileged access, and so on. Alert (3) : Information about actions that might be used to attack the system.
`argv[4]`	String	UTC Time	The UTC date, formatted as YYYYMMDDhhmmss, where YYYY is the year, MM is the month ( `01` to `12` ), DD is the day ( `01` to `31` ), hh is the hour ( `00` to `23` ), mm is the minute ( `00` to `59` ), and ss is the seconds ( `00` to `59` ).
`argv[5]`	String	Attacker	The "initiator" of the action, if known.
`argv[6]`	String	Target ID	A two-digit code followed by a label, indicating the general computer subsystem affected by this action. For example, `02` : `FILESYSTEM` .
`argv[7]`	String	Attack Type	A brief summary of the alert.
`argv[8]`	String	Details	Detailed information on the alert.

You can get more details on these command line arguments in the HIDS documentation. The script/program will run using the same UID/GID of the idsagent program (the ids user/group). The script/program must exist on each individual client machine if you want it to run. Because the script/program is going to run as the ids user, it is unlikely that you will be able to perform any system-configuration changes as described in the HIDS documentation unless you create SUID-to-root scripts/programs (with the inherent security concerns with SUID-to-root scripts/programs). Standard output and standard error are both redirected to /var/opt/ids/error.log . Here's a simple example:

 root@hpeos001[response] #  ll  total 36 -r-x------   1 ids        ids         16384 Jul 16 15:56 ids_alertResponse -r-x------   1 ids        ids           203 Oct 15 18:35 myprog.sh -r-x------   1 ids        ids           573 Aug 24  2001 send_alert_to_vpo.sh dr-x------   2 ids        ids            96 Sep 16 15:52 vpo root@hpeos001[response] #  cat myprog.sh  #!/sbin/sh echo "my response program" id echo "Arg 1 = "  echo "Arg 2 = "  echo "Arg 3 = "  echo "Arg 4 = "  echo "Arg 5 = "  echo "Arg 6 = "  echo "Arg 7 = "  echo "Arg 8 = "  root@hpeos001[response] #

Here's some output created by it:

 root@hpeos001[ids] #  pwd  /var/opt/ids root@hpeos001[ids] #  more error.log  ... my response program uid=105(ids) gid=104(ids) Arg 1 =  013 Arg 2 =  01 Arg 3 =  3 Arg 4 =  20031015173820 Arg 5 =  User ID:1 Arg 6 =  02:FILESYSTEM Arg 7 =  World-writable file created Arg 8 =  User 1 created "/var/X11/Xserver/logs/X0.log" with world writeable permissions executing /usr/bin/X11/X(1,35228,"40000007") with arguments ["/usr/bin/X11/X", ":0",  "-auth", "/var/dt/hpeosAAAa02610"] as PID:8744 root@hpeos001[response] #

30.3.11 Conclusions on HIDS

HIDS can be an extremely useful tool for monitoring a large collection of machines for unauthorized access and suspicious tampering of critical resource. HIDS will put additional pressure on resources on the monitored and monitoring systems. As with any kind of auditing, you need to decide whether the additional workload that HIDS will impose on individual servers is acceptable. There is no simple answer to this except to finely tune your Detection Templates to your own specific needs.