9.6. HIDS on BSD

While not as glamorous as NIDS, HIDS can be extremely valuable in detecting an attack that has actually been successfully carried out. One of the big failings with most NIDS systems is their inability to recognize if an attack launched against a host was successful in compromising the host. From the perspective of watching network traffic and assembling signatures for successful exploitation, NIDS have a long way to go.

However, once an attacker has broken in, he will likely leave footprints all over the system. Files will be created or modified. Processes will be terminated. Kernel parameters may be changed. A HIDS should be able to detect at least some of these footprints and alert youto the fact that something has gone very wrong.

HIDS come in many shapes and sizes on FreeBSD and OpenBSD. One of the most important features of HIDS in even the smallest networks is the ability to remotely manage and monitor the HIDS process. Tripwire is one of the oldest and best-known HIDS. Tripwire, initially released by Purdue University in 1992, works by looking for changes to files on a system. The assumption is that if an attacker breaks into a host, she will modify core system files in an effort to leverage the host for more attacks. For instance, an attacker may install Trojan horses in place of system utilities like ls(1) and netstat(1).

In Tripwire, files are initially checksummed using a hash like MD5. These hash values are used as the known good starting point for the system. At some periodic rate (nightly, weekly, and so on), the files are rehashed and the hash values are compared against the original values. If a hash has changed, Tripwire will generate an alert. The problem is that the open source version of Tripwire does not natively provide functionality for remote management or monitoring of alerts. In 1998 the Tripwire utility was acquired by a company now known as Tripwire, Inc. Their publicly available source still provides basically the same functionality as the original Purdue release. However their commercial product has been modified to suit the needs of large-scale enterprises. In order to centrally manage the open source release of Tripwire, you will need to roll your own form of centralized management.

Fear not! There are open source HIDS that provide Tripwire-like functionality and are manageable and monitorable on an enterprise scale.

9.6.1. Osiris

Osiris is a distributed host integrity verification program designed to detect changes to a host that may be the result of an intrusion. Unlike antivirus programs, which examine files on a host to look for specific traces of a virus, Osiris simply looks for any change. This allows a system administrator to decide if the change is due to a security problem or was expected.

Osiris utilizes a client/server model that allows it to scale. It has a central management daemon (osirismd) that stores configuration information and logs changes to client systems. By using a central management daemon, configuration changes can be made at a single location and pushed to remote clients automatically. Also, because the logs of what has changed on the client hosts are stored and compared locally on the central management server, patterns in changes are easy to recognize. For instance, if a new system administrator is hired and his user account is added to all your servers at once, the Osiris report will present this change in an easy to understand fashion. The management server is controlled by the management utility (osiris) that allows real-time updates to the configuration of the management daemon.

Whatever host integrity tool you are running, it is of little use if you do not have a known good starting point. Your initial scan of a host should be performed when it is in a secure state and you are sure none of the files you want to monitor have been maliciously altered. This may be easier said than done, however, especially if you have a large, preexisting server base. So, sometimes you just have to take a leap of faith on your initial scan. The author of Osiris maintains an online database of known good checksums for many versions of various operating systems. If you have a checksum of a binary that you don't know if it has been modified, check out http://www.knowngoods.org/.

On the client side, Osiris has a scan agent (osirisd) that retrieves its configuration from the management server, scans the local host, and returns results. Figure 9-10 shows the relationship between the components of Osiris.

Figure 9-10. Structure of Osiris

9.6.2. Installing and Configuring Osiris

Like many other popular utilities, Osiris is in the FreeBSD ports tree. OpenBSD administrators must obtain the source directly from http://osiris.shmoo.com/. Not only can you install Osiris, you can also make a tarball of the Osiris management console software or agent software. In the Osiris source directory, use make console to create the management console package and make agent to make the agent package. The agent package is particularly useful as it allows you to have a complete package that can be deployed to multiple hosts rapidly.

Once Osiris is installed, start osirismd and point it towards the directory where it will store information. By default, this is /usr/local/osiris.

% sudo osirismd -r /usr/local/osiris

The first time the management console starts, it automatically creates certificates to use for secure communication with the scan agents. Once this is done, you are prompted as to whether or not you want to trust the newly created certificate. Select yes and you find yourself at a username prompt. Enter a username of admin and an empty password to access Osiris. At the osiris prompt, run edit-mhost to set up variables on the management console. Edit the values in the configuration to suit your needs as shown in Example 9-2.

Example 9-2. Using edit-mhost to set up Osiris

osiris-4.0.5-release: edit-mhost [ edit management host (localhost) ]   > syslog facility [DAEMON]:    > control port [2266]:    > http host name (uses system name by default) []:    > http control port [2267]:    > notify email (default for hosts) []: [e-mail]   > admin email (gets all mail)[]:  [e-mail]   > notification smtp host [127.0.0.1]: mail.test.com   > notification smtp port [25]:    > authorized hosts:    127.0.0.1   Modify authorization list (y/n)? [n]  [ management config (localhost) ] syslog_facility = DAEMON control_port = 2266 http_port = 2267 http_host =  notify_email =  [e-mail] admin_email =  [e-mail] notify_smtp_host = mail.test.com notify_smtp_port = 25 hosts_directory =  allow = 127.0.0.1

Once these changes are made, they take effect with osirismd automatically.

Now you need to bring up the scan agents on the hosts you wish to monitor. A good starting point is the host that osirismd is running on. Untar the tarball you made in the install process and execute the install.sh script within the created directory. Once the scan agent is installed and started, go back to the management console prompt and run the new-host command, as shown in Example 9-3. new-host needs to be run for each scan agent that is brought online. The options in the new-host script are relatively straightforward and are easily tailored to your environment. At the end the configuration, Osiris pushes a default configuration to the scan agent based on the OS of the host and then starts the baseline scan.

Example 9-3. Running new-host for every host you want to mointor

Is this correct (y/n)? y  >>> new host (management) has been created. Initialize this host? (yes/no): yes Initializing a host will push over a configuration, start a scan, and set the created database to be the trusted database. Are you sure you want to initialize this host (yes/no): yes OS Name: FreeBSD OS Version: 5.2.1-RELEASE use the default configuration for this OS? (yes/no): yes  >>> configuration (default.freebsd) has been pushed.  >>> scanning process was started on host: management

At this point, the scan kicks off and Osiris returns to its prompt. Repeat this process for all the hosts you wish to scan and you'll have a functioning Osiris environment.

There are a variety of configuration (and reconfiguration) commands available at the Osiris prompt. A simple question mark (?) at the prompt brings up the listing including commands to list databases, modify agent configurations, and manually kick off scans.

9.6.3. Running Osiris

Osiris will automatically scan hosts based on the scheduling information you supplied during the agent configuration. If a change is detected, an email will be sent to the notification email address. It is then up to the person notified to determine if the change was a valid one. For instance, Example 9-4 shows an email from Osiris alerting that the netstat utility has changed.

Example 9-4. Sample Osiris alert about netstat

If these changes are approved, visit the URL below to set the latest scan database to be the trusted database. Or, login to the management console and set the trusted database to 60.If these notifications persist, you may need to modify the scan config for this host.     <https://management.test.com:2267/?host=management&base_db=60> Change Statistics: ----------------------------------         checksums: 1        SUID files: 0  root-owned files: 0  file permissions: 0         new files: 0     missing files: 0 total differences: 4      compare time: Fri Sep 19 23:27:37 2003              host: management          log file: no log file generated, see system log.           base db: 59        compare db: 60 [management][cmp][/usr/sbin/osirismd][checksum][ db717c99abad90ab290f40b157cca2c9,  22f6408a505991a8a7a69d9bffe93611] [management][cmp][/usr/sbin/osirismd][mtime][Mon Feb 23 16:34:04 2004,Mon Nov 1  13:12:52 2004] [management][cmp][/usr/sbin/osirismd][ctime][ Mon Feb 23 16:34:04 2004, Mon Nov  1 13:12:52 2004] [management][cmp][/usr/sbin/osirismd][bytes][ 106344,6073419]

On the face of it, this change seems pretty suspect. The netstat binary should only change with a system upgrade or if it's patched for some reason. Further, it has been replaced by a binary that is 6 megabytes in size, versus the 106 kilobytes it originally was. This incident is definitely worth exploring.

A quick word on system updating. When performing a large-scale upgrade, such as upgrading FreeBSD from source, tools such as Osiris can really become unwieldy. Many system libraries and utilities will be modified creating a massive number of deltas that need to be examined. It is usually impossible to validate all the changes made by the system during an upgrade. This is one of those times when you may need to take a leap of faith and create a new database assuming the new host is still trusted to be safe.