Osiris User HandbookContents:
A. Installing Osiris1. About Osiris1.a. Introduction Osiris is a host integrity monitoring system that can be used to monitor changes to a network of hosts over time and report those changes back to the administrator(s). Currently, this includes monitoring any changes to the filesystems. Osiris takes periodic snapshots of the filesystem and stores them in a database. These databases, as well as the configurations and logs, are all stored on a central management host. When changes are detected, Osiris will log these events to the system log and optionally send email to an administrator. In addition to files, Osiris has the ability to monitor of other system information including user lists, group lists, and kernel modules or extensions. Some integrity monitoring systems are signature-based, that is, they look for specific file attributes as a means of detecting malicious activity. This type of approach to host integrity can be very cumbersome to manage and can lead to unauthorized change going undetected. Osiris is intentionally not like this. Osiris will detect and report changes to a filesystem and let the administrator determine what (if any) action needs to take place. There are no complicated assumptions or dumbing-down of information. If a change occurs, it can be detected and reported. All Osiris components compile and run on both Windows and common UNIX systems, including BSD, Linux, Mac OS X and Darwin, AIX, IRIX, and Windows NT/2K/XP. This allows for the flexibility to manage all types of platforms from either a UNIX or Windows environment. Osiris has a modular interface that allows developers to easily extend what the scan agents are capable of monitoring. See the modules page for details. 1.b. Overview of Components Osiris consists of three major components: the management console (osirsimd), a scan agent (osirisd), and a CLI management application (osiris). At the present time, the management application uses only a command-line interface. osiris <==> osirismd <==> osirisdThe management console should be deployed on a trusted host. This is where all of the information about managed hosts are kept, including configs, logs, and databases. This process runs as an unprivileged user. The scan agent is a lightweight process that runs on each monitored host. The scan agent is responsible for scanning the local filesystem and sending the data back to the management host. On UNIX systems, as well as Linux, the scan agent runs with privilege separation. The root process exists only to open privileged files during a scan. (files are never opened for write access, never). The management application is used by the administrator to manage the details of the scanned hosts. It communicates directly only with the management console. The management console has a very simple, portable, directory structure and can be tar'd or zipped and moved to any other supported system (if needed). It is organized as follows:
osiris/
|
|
`--certs/ - root cert (osirismd.crt)
|
`--configs/ - default and shared scan config files
|
`--filter.db - comparison filter database
|
`--hosts/ - host directories (see below)
|
`--osirismd.conf - management console config
|
`--private - user database, SSL key file
Each host directory under the “hosts” directory has the following structure:
example-host/
|
|
`--configs/ - scan config files
|
`--databases/ - scan database files
|
`--logs/ - comparison log files
|
`--host.conf - config for this host
1.c. General Considerations Before installing and using Osiris, it makes sense to consider certain issues such as the number of hosts you will be monitoring, the various platforms of monitored hosts, the location and security of your management console, and the environment you will be using to build Osiris. If you have installed Osiris from a ports tree of some kind, these issues have already been considered for you, feel free to skip to the next chapter (Using Osiris). If you will be monitoring more than a handful of hosts, a means of distributing the scan agent software to these hosts will be necessary unless you want to do that by hand. The osiris system currently does not have any way of remotely installing or updating scan agents. Osiris requires a single host to be used as a management console. Ideally, this host is a host dedicated to being an Osiris management console, running only necessary services and applications, and only available to the necessary administrator(s). The security of the management console is key to the integrity of the Osiris system as a whole. If the management console is compromised, all of the data associated with monitored hosts becomes useless (at least). It may be the case that your management host, or monitored hosts do not have a compiler on them. In that case, the management console and the agent software can be built offline, in a trusted environment. Obviously, you need to build the management console on the same platform, and build scan agent packages on the same platform(s) that you will be deploying them to. 2. Getting OsirisThe main distribution point for the osiris source code is here: http://osiris.shmoo.com/download.htmlCompilation on Windows is not fun, so PGP signed binary distributions for windows are also available at this download location. To get access to the latest unreleased top of tree source code, there is an anonymous Subversion mirror:
3. ConfigurationIf you have specific requirements for Osiris such as where the management console stores monitoring data, or the privilege separation user, then these things can be specified as arguments to configure. Most users will not need to customize the configuration and can simply use the defaults:
If not customizing, then proceed to the next section on compilation and installation. optional configuration parameters
By default, the management console stores all logs, config files, databases, and other files under the /usr/local/osiris/ directory. Over time, the databases directory may grow rather large and some administrators may wish to keep the osiris root directory somewhere else in the file system. To specify an alternate location, use the --with-root-dir=DIR as an option to configure, for example, to place the osiris root at /var/adm/osiris, do the following:
During installation, an unprivileged osiris user and group is created. The management console runs as this unprivileged user. In addition, the scan agent has two processes, one run as root, the other as the unprivileged osiris user as a form of privilege separation. To change the name of this unprivileged user, use the --with-osiris-user option to configure. If you wish the management console to run as a different user than the scan agent, use the --with-md-user option. To specify an alternate directory where the management console can find its configuration file (osirismd.conf) use the --with-md-conf-dir option. By default, configure attempts to find the location of OpenSSL on your system. If not found, you may have to explicitly tell configure where OpenSSL is. Use the --with-ssl-dir=DIR option. There are some experimental features of the Osiris command line that provide a command history list using the up-arrow key as well as command completion. To enable this, use the --enable-fancy-cli option. By default, Osiris will use libreadline (if installed) unless this option is specified. 4. Compilation and InstallationIf you your plans are to simply install the management console on a single host, and monitor only that host, then compilation and installation is as simple as doing:
However, if you are planning on monitoring multiple hosts, or your management host does not have a compiler, then you will need to build the installer packages. 4.a. Management Console To build an installer package for the management console, use the 'console' make target:
This will produce a tar.gz file containing the binaries and an installation script located in the src/install/ directory. The name of the file will include the Osiris version, Operating System, and system architecture (e.g. x86). Transfer this tar.gz file to the management host, unpack it and run the installer script as root (or equivalent):
This script will create the user and group needed and prompt you for which components to install. When installing the management console, it is recommended that you also install a local scan agent as well as the command line interface.
The install script will also install startup items for the management daemon and the scan agent if installed. When prompted for starting the daemons now, choose yes. 4.a. Scan Agent To build an installer package for the scan agent, use the 'agent' make target:
This will produce a tar.gz file containing the binaries and an installation script located in the src/install/ directory. The name of the file will include the Osiris version, Operating System, and system architecture (e.g. x86). Transfer this tar.gz file to each like platform to be monitored. Unpack the installer package and run the installer script as root (or equivalent):
Repeat this for each host to be monitored. For example, if you plan on monitoring 20 linux boxes, and 3 FreeBSD, you would need to build one Linux agent package, and one FreeBSD agent package. Currently, the Osiris system does not include a means of distribution and this is the responsibility of the administrator. There are some suggestions for agent distribution and automated integration into the management console that can be found on the contribution section of the Osiris site. 5. Configure the Management ConsoleAfter the management console has been installed, some initialization is necessary. The steps presented here are simply suggestions. Configure your management console according to your needs/requirements/security policy as necessary. To configure settings for the management console, use the 'edit-mhost' command. This will invoke a series of questions. If you are unsure of a setting, just accept the defaults. Login as the user admin with no password.
The following list is a description of each setting: syslog facility: this is the facility that the management console will use for all logs. Logs include everything from the status of the management daemon, to communication with agents, and scan comparison logs. control port: this is the port that the management console listens on for communication with the CLI. If you will be connecting to the management console from other hosts, make sure the firewall has this port open. http control port: this is the port that the management console listens on for web based confirmation of changes. When changes are detected, if this port is enabled, any email notifications will contain an URL that allows the administrator to confirm the changes and reset the trusted database. By default, this feature is turned off. It is here merely as a convenience for administrators that wish to manually acknowledge changes. Do not enable this feature unless you know you require it. notify email: this is default email address that all changes will be sent to for hosts that have email notification turned on. The default value is not set. notification smtp host: this is the host running an smtp server that the console will use to send mail. The management console does not have a built-in MTA. The default assumes the local host is running an smtp server. notification smtp port: this is the port that the notification smtp host accepts smtp requests on. The default is 25. authorized hosts: The management console has an access control list that specifies exactly which hosts are allowed to connect to the control port on. By default, this list includes only 127.0.0.1. You can add hosts specifically to this list, or you can use regular expressions to add a group of hosts. Adding "*" is not recommended since this will allow any host to connect.
6. Adding a HostFor each scan agent deployed, you will need to establish a host profile under the management console. A host is added with the 'new-host' command. Assuming the management console was recently configured, it makes sense to add and configure the agent running on the management host:
After the host has been created, the management console will ask to initialize it. What this means is that the management console will determine what Operating System is running on the host, suggest a default scan configuration to use, and start an initial scan to create a baseline for this host. It is not necessary to initialize right away, you can always come back and initialize this host with the 'init' command. In this case, we will initialize the agent running on the management console:
We can see the status of the host at any time by using the 'status' command:
For reference, the following list is a description of each host setting: name: the short name associated with this host, keep this small but descriptive as this is the name that is used whenever you reference the host in the CLI, and is what is sent out in notification mails and logs. hostname: the IP address or hostname where this host can be contacted at. description: a small description of the host (e.g. "dev-test solaris 9") that is printed out when you list the hosts. agent port: this is the port that the agent is listening on. By default this is 2265. Do not change this unless you have a reason to. If you do, be sure that the agent is started and told to listen on the same port (-p option) or else communication will be lost. enable log files: When enabled, each scan report will produce a new log file under the /logs directory for this host. This is useful if you wish to keep separate log files for each scan, for records, or forensic purposes. Keep in mind that ALL of these log entries are sent to syslog on the management console and that is the recommended means of collecting and dealing with logs. It is not recommended that this feature be enabled. The default is 'no', disabled. archive scan databases: After each scan, a database is created. Turning this feature on saves each scan database, even if it is identical to the previous scan. Again, it is not recommended that this feature be enabled unless you need it. The default is 'no', do not archive databases. auto accept changes: Each host has a baseline database that is compared with the database created after each scan. Enabling this feature automatically sets the baseline database to be the newly created database if changes are detected. By default, this is turned on and it is recommended that this be enabled unless you have reason to disable it. If you wish to manually reset the baseline database, turn this feature off. purge database store: in order to prevent scan database files from accumulating on the management console, this feature automatically deletes databases older than the baseline. It is recommended that this feature stay enabled. If you need access to previous databases, turn this feature off. Note: all changes are sent to the logs so unless you need a forensic trail of all monitored items for a host, it is recommended that this feature stay enabled.email notification: turning this feature on will send email to the notify email address set for this host, or to the default address set under the management settings. If disabled, no email notifications for this host will be issued. notify on scan failures: enabling this feature will send mail to the administrator in the event that a scheduled scan was not able to be started. The failure reason is included in this email notification. notify on no changes: enabling this feature will send mail to the administrator after each scan, even if there are no changes. If disabled, notifications are only sent when changes are detected for this host. notify on session rekey: enabling this feature will send mail to the administrator each time the agent loses it's memory resident session key. This is the key that is established between the management console and the agent. If the agent is restarted, or the box is rebooted, the key is lost. This enables the administrator to be informed of someone has restarted the daemon, or the box has rebooted. notification email: the email address for the administrator of this host. If left blank, the default address in the management console settings is used. scheduling date/period: scheduling works by setting a start date and time, and a period in minutes. The default is the current date and time. This is usually fine unless you have specific requirements for when this host is scanned. For example, to scan a host every day at 2 a.m., you would enter some date and 2 a.m. Then, a period of 1440 minutes (daily). activate: The scheduler only schedules scans for activated hosts. If you disable a host, the scheduler ignores it. However, you can still communicate and manually kick off scans on disabled hosts. Notifications and logs all work the same. 6. Where to go from hereAt this point, the management console has been installed and configured. In addition, a scan agent is running on the management console and a baseline database has been configured. To add more hosts, follow the example above. For more details about using osiris, go on to the next section Using Osiris. The most current documentation is always online. In addition, there are mailing lists available for developers, and users. If you still need help, or have questions or suggestions, feel free to send mail to me at brian at shmoo.com. B. Using Osiris1. How Scheduling WorksThe built-in scheduler is responsible for telling the managed hosts when to start a scan. When it is time for a host to be scanned, the scheduler does the following:
The scheduler pushes the scan config each time to ensure that the managed host has the correct scan config loaded. The current scheduler is limited to scheduling scans based off of a single config. 2. Scan DatabasesWhen a host is scanned, all scan data is sent back to the management host. None of the information collected is ever kept on the filesystem of the managed host. This is done in an attempt to preserve the integrity and confidentiality of the scan data. The management host stores scan data in Berkeley DB files. Each scan database contains some meta data, the scan entries, and any errors that may have occurred during the scan. The databases are formatted in such a way that they can be moved across platforms or machines with different byte ordering. This makes it easy to migrate a management host to a different platform with little hassle. This is also handy in a forensic situation by allowing a timeline of scans to be analyzed on any of the supported platforms. The scan database files are considered read-only and are even created so as to not allow write privileges to any user. Thus, database files are NEVER altered in any way by any of the Osiris executables. Each host has one database that is considered the base, or trusted, database. When a subsequent database is created, it is compared against the base database in order to determine if any changes have occurred. Since databases are never altered, change management is handled by changing which database is the trusted database. More information on this in the section below, Dealing with Detected Changes. Hosts can be configured to have database archiving enabled or disabled. In most cases, it is sufficient to disable archiving, but your security policy might require that each database be kept and stored for some period of time. If archiving is enabled, keep in mind the scan frequency and size of each database when determining disk space requirements. The following table lists the file attributes scanned with each scan record type:
Viewing Database Contents At times, it may be necessary to view the contents of a scan database. The command line interface allows for this with the print-db command. Use the list-db command to view a listing of databases. The print-db command will then enter a subcommand mode for that database that allows for the printing of the database header, file record listing, specific file details, system record listing, and any errors that were encountered while scanning. For example:
3. Dealing with Detected ChangesThe use of Osiris can vary in purpose, but the bottom line is that the administrator desires to be notified of certain changes and not others. Whatever the case, there are always unanticipated changes. Software is upgraded. Security alerts trigger patches to critical parts of a system. When the latest scan produces information that differs from the trusted state, log entries are created and email might be sent to the administrator listing the detected changes. Unless action is taken, the subsequent scans will report the same changes and, depending upon the host's configuration, continue to notify the administrator. Since databases are not altered, the way to "acknowledge" changes is to change what is considered the trusted database for that host. There are two ways to do this:
4. NotificationsCurrently, the only supported notification is email. Although monitoring of the logs is strongly recommended, it can be very convenient to be notified of changes by email. Hosts can be configured to notify the administrator after each scan, or only when changes are detected. A warning notification is issued in the event that a scheduled scan fails for any reason. A notification consists of statistics related to the scan as well as all of the log entries associated with any detected changes. If the http server is enabled, a URL is also specified to provide the recipient the opportunity to update the trusted database via an SSL enabled web browser. The following is an example of a notification after updating some executables:
5. Comparison FiltersSometimes it may be necessary to monitor only certain attributes of files. For example, it is common for log files to change in size and content but the permissions should probably never change. Comparison filters allow certain changes to exist without triggering a log entry. One of the biggest problems with IDS systems is that they often become noisy, or issue bothersome alerts that eventually numb the administrator to the point where events are ignored or not given proper attention. Comparison filters allow an administrator to specifically single out changes that should be ignored, or changes that should given attention so that notifications become more meaningful. Filters are basically a list of regular expressions. Use the filters command to list your currently installed filters. Use the edit-filters to spawn an editor and edit the filter list. 6. Custom Scan ConfigurationsOsiris ships with default scan configs, but you will likely want to modify those or create your own. The "configs" directory in the osiris root on the management host contains all of the default configs, e.g. default.linux These are the configs used during the init process and when a host is created. Feel free to modify these files so that the addition of new hosts can take advantage of the custom configs. The config files in this directory are known as shared because any number of hosts can take advantage of them. This makes it easy to monitor many similar hosts and be able to make changes to their scan by editing a single config file. At any point in time, you can view the config used to create the trusted database for a host, use the config command:
For hosts that require very customized configs, you may choose to store it under that host’s configs directory. The only real advantage of this is that the main ‘configs’ directory will not get cluttered with customized configs. To create a new config, use the new-config command. To create a config in the shared configs directory, just provide a name:
Or, to add a config to be used only for a specific host:
Once a config has been created, it can be edited with the 'edit-config' command. This command will download the config and open it in an editor on the local machine. If saved, the modified config will be sent back (saved) to the management host. Note that editing the config will most likely generate a different database signature and generate log entries. To list all of the configs, use the configs command. To verify that a config is syntactically valid, use the verify-config command. The verify command will also print any errors and their line numbers. For details on the syntax of scan configurations, see Appendix 1. 7. Logging7.a. System Logs The management console logs to the system log (syslog on UNIX platforms and the Event Viewer on Windows). Syslog parameters (facility and level) are specified in the management console’s configuration file. There are three levels of logging: low, medium, high. The low setting has only critical events sent to the log. The high setting is the most verbose. 7.b. Log Files If a the log_to_file attribute is enabled for a host, a log file is created after each scan. The log details the results of the comparison. Comparison logs are always sent to the system log regardless of the log level. This cannot be turned off. Scan agents do not log anything related to scans to the system log, only events related to the status or state of the daemon itself. This is by design. The goal is to keep sensitive information in a central location for reasons of security and usability. 7.c. Log Formats The log formats sent to syslog and the EventViewer are as follows:
If the host field is not applicable, it is "*". The type field is one of:
For logs of type cmp, the message field has one of the following formats for new, missing, and altered items:
For example, here is an informational log entry:
The path is a full path of the file in question. The attribute is the attribute that has changed (e.g. inode, mtime, or checksum). The third field contains two values: the trusted or initial value for the attribute and the current value separated by a comma. For example, here is a comparison log entry that shows that the mtime value for “/bin/ln” has changed:
8. Further Information and SupportThe most current documentation is always online. In addition, there are mailing lists available for developers, and users. If you still need help, or have questions or suggestions, feel free to send mail to me at brian at shmoo.com. Appendix 1: Scan Configuration ReferenceScan configs are used to dictate exactly what is scanned on a host. Osiris ships with default configs for many platforms, so you have a decent starting point. The config syntax for Osiris is very similar to the config sytnax used by Apache. A scan config consists of a global section, and a list of blocks. Each block represents a directory and contains options for that block, as well as rules used to include or exclude certain files. Blocks are specified within directory tags:
If an option is not specified, the global value is assumed. If no rules are listed then the default rules are assumed. If a block is a subdirectory of another block, the subdirectory block takes precedence. Options Options dictate the nature of the scanning that takes place in the directory. Usually options appear first in the block, but their placement within the block has no signifigance or precedence. Options not found within a specific block are said to be global. If no global value is specified, there is a default value for each option. Currently supported options are as follows: Recursive <bool> if set, this osiris will recursively scan this directory, otherwise, only a top level scan will be done. FollowLinks <bool> if set, osiris will follow any symbolic links it encounters. If symbolic link is a link to a directory, it will only follow that link if the the recursive option is set. Hash <hash> specifies the hash algorithm to be used for all files in the directory. Algorithm may be one of: md5, sha, or ripemd boolean values must be one of: yes, y, 1, true, yup, no, n, 0, false, nope and the hash value must be one of: md5, sha, ripemd (for MD5,SHA-1,and RIPEMD-160). Rules a rule serves to include or exclude files, either specifically, or by property. The order of the rules is important. When a file is encountered during a scan, the rules for that block are analyzed in the order they are listed. If a rule catches a file, the information about the file is stored in the resultant database. Otherwise, it is ignored. The list of rules and their formats are as follows: IncludeAll Include all files, all files will be caught under this rule. If a block contains no rules, this is the default rule assumed. ExcludeAll Exclude all files. Include <filter> Include any files that pass the specified filter. Exclude <filter> Exclude any files that pass the specified filter. NoEntry <directory> The specified directory is not entered and the directory file itself is also ignored. The directory specified should be relative to the block. For example, to exclude the contents of /usr/local/src as well as the /usr/local/src directory file itself, use the following rule:
The NoEntry directive does not support regular expressions and is case sensitive except on Mac OS X and Windows, where case is ignored. No quotes are required. Filters In every block of the scan config, including the global block, there will at be at least one filter. If no filters are specified in a block, the global filter will be used. Filters are found as part of a rule. Specifically, you include filters after an 'Include' or 'Exclude' rule. For example, the following two statements include filters that will catch, or include, the files that are perl scripts or any file owned by user bob:
Filters are designed to catch files of a particular type, or files that share a specific attribute. The information used to create many of the filters found in osiris are derived from the unix file(1) utility. The following is a list of the currently implemented filters, and their official definitions: sticky any directory or file that has the sticky bit set. For operating systems that do not support the sticky bit, this filter does not apply and has no effect.suid any file that has the suid bit set.sgid any file that has the sgid bit set.executable All ELF binaries. FreeBSD/OpenBSD - all files that begin with any of the following 4 byte long expressions:
(4 bytes) & 0377777777 = 041400407
(4 bytes) & 0377777777 = 041400410
(4 bytes) & 0377777777 = 041400413
(4 bytes) & 0377777777 = 041400314
BSDi - files that begin with any of the following bytes:
0xCC, 0x107, 0x108, 0x10b
Linux - files that begin with any of thefollowing 4 byte long values:
0x00640107
0x00640108
0x0064010b
0x006400cc
or
\01\03\020\04
\01\03\040\04
Solaris/SunOS - all files that begin with any of the
following 4 byte long expressions:
(4 bytes) & 077777777 = 0600413
(4 bytes) & 077777777 = 0600410
(4 bytes) & 077777777 = 0600407
(4 bytes) & 077777777 = 0400413
(4 bytes) & 077777777 = 0400410
(4 bytes) & 077777777 = 0400407
(4 bytes) & 077777777 = 0200413
(4 bytes) & 077777777 = 0200410
(4 bytes) & 077777777 = 0200407
Darwin
(4 byte header: feadface)
perl any file that contains, within the first thirty bytes, any of the following strings: "/bin/perl", "/usr/bin/perl", "/usr/local/bin/perl".python any file that is a python script, a python text executable, or a python compiled file. Specifically any file with any of the following attributes:
- first three bytes: \032\032\032
- first four bytes: \010\013\078\153 ( little endian )
script any shell script or script, including sh, csh, bash, ksh, tcsh, ksh, ash, ae, nawk, gawk, awk, rc, env. The file must begin with the string: "#!" or "BEGIN" and must contain one of the following within the first 25 bytes:
/bin/sh
/bin/csh
/usr/local/bin/bash
/bin/bash
/bin/ksh
/bin/tcsh
/usr/local/tcsh
/usr/local/bin/tcsh
/usr/local/bin/zsh
/usr/local/bin/ash
/usr/local/bin/ae
/bin/nawk
/usr/bin/nawk
/usr/local/bin/nawk
/bin/gawk
/usr/bin/gawk
/usr/local/bin/gawk
/bin/awk
/usr/bin/awk
/bin/rc
/usr/bin/env
gzip any GNU zipped file or jar file, specifically, any file that begins with the following two bytes: \037\213zip any file created with winzip, or zip, specifically, any file that begins with the first four bytes: PK\003\004tar any file created with tar, or GNU tar utilities, specifically, any file that contains the string "ustar" at byte positions 257-261.pgp any PGP public keyring, security ring, encrypted data, ascii armored data, public key block, message, signed message, or signature. Specifically, any file that begins with any of the following two bytes (little endian shown):
0\153
1\153
1\149
0\149
0\166
or the follwing string:
-----BEGIN\040PGP
rpm any rpm package file, specifically, any file that begins with the following four bytes: \237\171\238\219uid(x) any file that is owned by the uid: xgid(x) any file that is a member of the group: xsid(x) Windows only: any file that is owned by the specified SIDuser(x) any file that is owned by user: xgroup(x) any file that is a member of the group: xheader(x) any file that begins with the literal hex value: xfile(regex) any file that has the name matching the regular expression specified. Note that the regex is case insensitive, meaning that "regex" will
match against "regex", "REGEX", "ReGex", and so on.
Here are some examples: include the /etc/motd file: Include file( ^/etc/motd$ )
Exclude any file beginning with a dot:
Exclude file (^\. )
Exclude any file ending in ".log" in the /var/log directory:
Exclude file( ^/var/log/.*\.log$ )
Exclude any file containing the substring "ignore":
Exclude file( ignore )
suffix(x) any file that has a name with the format: *.xmd5(x) any file that has an MD5 checksum value of: xsha1(x) any file that has an SHA-1 checksum value of: xripemd(x) any file that has an RIPEMD-160 checksum value of: xpermissions(x) any file that has a permissions string with the format: x. The character '*' can be used for a wildcard to denote that any value for that bit is acceptable. Substrings can also be used. For example, to specify all files that have owner read bit set, use: "*r" as a value. To speicfy all files with suid bit set, use: "***s", this is essentially the same as using the suid filter.Global Blocks The global block does not apply to any specific directory and is not within any tags. All options are valid in the global block. The only valid rules in the global block are IncludeAll and ExcludeAll rules. Modules Block The modules block allows for any compiled-in modules to be included in a system scan. There is only one modules block. Use the following tags to designate the modules block:
The following built-in modules are included with the scan agent: mod_users: monitor user databasemod_groups: monitor group database mod_kmods: monitor kernel extensions or services mod_ports: monitor listening network ports (windows and linux only) Use the Include keywords to use these attributes, for example:
See http://osiris.shmoo.com/modules for information on how to obtain or develop modules for the Osiris scan agent. Default Configuration Global options are assumed if not specified. However, if no global option is specified, the default values for options are as follows:
Example Scan Configuration The following is the included default config for Mac OS X. It scans most of the executable directories as well as root's home and the NetInfo database files.
Appendix B: Platform Specific IssuesMention of platform or OS specific issues surrounding Osiris are listed below. Although Osiris has been designed to work in a similar fashion on all platforms there are sometimes small functional differences with each of the disparate platforms it runs on. Mac OS XResource Forks - With HFS+ filesystems on Mac OS X, some files may still have resource forks; some applications still make use of this characteristic of the filesystem. The Osiris scan agent automatically checks for resource forks on each file that is scanned. If the resource fork exists, it is scanned and monitored. At this time, this behavior is not configurable. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright 2005 The Shmoo Group. Questions, Comments, Corrections? Email brian@hostintegrity.com. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||