Document Information

Document Name: / HP-UX 11i Preliminary RBAC Auditing Assessment and Setup
October 2012
Document Version No: / 1.1
Prepared By: / Dusan Baljevic / Preparation Date: / 8 October 2012

Distribution List

From / Date / Phone/Fax /
Dusan Baljevic / 8 October 2012 / 0412 041 715
To / Action* / Due Date / Phone/Fax /
Inform

Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Modification History

Version / Owner / Date / Description /
1.0 / Dusan Baljevic / 8 October 2012 / New document
1.1 / Dusan Baljevic / 22 October 2012 / Updates

1. Introduction 4

2. SSH with RBAC and Keystroke Logging 5

3. RBAC Setup with Privileged Shell 6

4. Basic Security Recommendations 7

5. HP-UX Auditing Setup 8

6. Disable HP-UX Auditing 10

7. View Audit Logs 11

8. Web-Based Audit Reporting 13

9. General Guidelines for HP-UX Auditing 15

1.  Introduction

This document serves as a template for setting up basic Role Based Access Control (RBAC), keystroke logging, and auditing, as per brief requirements provided by XYZ.

The scope of the project can be extended in the future.

2.  SSH with RBAC and Keystroke Logging

Starting with the HP-UX RBAC B.11.31.05.01 and HP-UX SSH A.05.90 releases, keystroke logging when enabled now will successfully create a keystroke log file for a SSH login session. The HP-UX RBAC Keystroke logging feature is only supported on HP-UX 11iv3.

Installation of RBAC release B.11.31.05.01 installs RBACExt and RBAC patch:

# swlist -l product |grep -i rbac

PHCO_41859 1.0 rbac cumulative patch

RBAC B.11.31 HP-UX Role-based Access Control

RBACExt B.11.31.05.01 HP-UX Role-based Access Control Extensions

The steps to configure RBAC keystroke logging for SSH sessions:

·  Add libpam_keystroke.so.1 library to 'sshd' service. Note: it can be added to other services as needed:

# vi /etc/pam.conf

...

# Session management

#

sshd session required libpam_hpsec.so.1

sshd session required libpam_unix.so.1

sshd session optional libpam_keystroke.so.1

·  Modify RBAC configuration file rbac.conf to support keystroke logging and define logging location:

# vi /etc/rbac/rbac.conf

...

# Keystroke Logging enabled: If this flag is set to 1, then keystroke

# logging is enabled on the system, otherwise it is disabled.

KEY_STROKE_LOGGING = 1

# Location of keystroke log file: An administrator may specify the

# directory location in where the keystroke logs should reside.

# If this location is not specified, the default is "/var/adm/rbac".

KEY_STROKE_LOCATION = /var/adm/rbac

# Banner page logging: The banner page will be logged if the below

# flag set to 1; otherwise, it will not be captured in the log file.

# The default is to omit the banner.

KEY_STROKE_BANNERPAGE_LOG_ENABLE = 1

·  Set key filter. An example:

# vi /etc/rbac/key_filter

newadm:*:dflt:dflt:ks_all

·  Ssh into the server as user newadm and run some commands.

·  Check log file. For example, for user newadm:

# more /var/adm/rbac/klog-newadm-ssh-Mon_Oct_22_2012_12:41:16-8933

3.  RBAC Setup with Privileged Shell

·  Create a new system administrator account and set the Shell as /usr/bin/privsh or /usr/bin/privksh (depending on the company’s policy of default Shells):

# groupadd wheel

# useradd -g wheel -s /usr/bin/privksh -m newadm

# passwd newadm

# roleadm assign newadm Administrator

# cat /etc/rbac/user_role

root: Administrator

newadm: Administrator

·  Set up commands that newadm will be allowed through RBAC in command file /etc/rbac/cmd_priv:

# vi /etc/rbac/cmd_priv

For example, enable these lines to add new users:

/usr/sbin/useradd :dflt :(hpux.user.add,*) :0/0// :dflt :dflt :dflt :

·  The permissions of the RBAC command file must not be restrictive to allow read access:

# ls -als /etc/rbac/cmd_priv

48 -r--r--r-- 1 root sys 18546 Feb 10 2011 /etc/rbac/cmd_priv

·  To test it, log in as user newadm and try to add a new user:

newadm$ useradd myfriend

privksh: useradd: not found

newadm$ /usr/sbin/useradd myfriend

The last command is successful because full path to command is used.

4.  Basic Security Recommendations

Some very simple recommendations follow. More comprehensive report can be provided as part of a separate engagement.

·  To disable direct root access unless logged via console. Set up file /etc/securetty with one line in it:

console

·  Disable direct root access via ssh. Edit /etc/opt/ssh/sshd_config:

PermitRootLogin no

·  Disable all insecure protocols in /etc/inetd.conf.

The security can further be increased by editing /var/adm/inetd.sec.

·  To restrict who can su(1M) to root: edit /etc/default/security:

SU_ROOT_GROUP=wheel

Then, simply add all admin accounts to Unix group wheel. The name of Unix group is arbitrary (historically set to wheel).

·  Root’s home directory should be /root, not / (which should be restricted through permissions 700).

·  Daemon flags for inetd to set up correctly in /etc/rc.config.d/netdaemons (flag "-p" to limit number of processes).

·  Daemon flags for inetd to set up correctly in /etc/rc.config.d/netdaemons (flag "-a" to enable user-level auditing of processes).

·  Daemon flags for inetd to set up correctly in /etc/rc.config.d/netdaemons (flag "-l" to enable logging).

·  Account root is set up with password expiration.

·  And many other possible improvements.

5.  HP-UX Auditing Setup

To enable auditing on the HP-UX 11i system, follow these steps:

1.  To audit all users, set the following in /etc/default/security:

AUDIT_FLAG=1

Or, to enable auditing per user, the userdbset(1M) command can be used:

# userdbset -u newadm AUDIT_FLAG=1 (enable auditing for newadm)

# userdbset –d -u newadm AUDIT_FLAG (disable auditing for newadm)

2.  Create customized auditing configuration file /etc/audit/audit_site.conf (it is one single line). The list of events can be more comprehensive – it depends on business requirements:

PROFILE XYZ = EVENT login, EVENT moddac, EVENT create, EVENT delete, EVENT modaccess, EVENT open, EVENT close, EVENT admin

PROFILE Supplement = EVENT readdac, EVENT process, EVENT removable

3.  To audit according to policy XYZ, enter the following command:

# audevent -P -F -r XYZ

4.  Use the audevent(1M) command with no options to display a list of events and system calls that are currently configured for auditing.

5.  Set the audevent(1M) /etc/rc.config.d/auditing file:

AUDITING=1

PRI_AUDFILE=/var/.audit/audtrail

PRI_SWITCH=1000

SEC_AUDFILE=*

SEC_SWITCH=0

NTHREADS=1

AUDEVENT_ARGS1="-P -F -r XYZ"

AUDEVENT_ARGS2=""

AUDEVENT_ARGS3=""

AUDEVENT_ARGS4=""

AUDOMON_ARGS="-p 20 -t 1 -w 90 -o /var/adm/syslog/syslog.log -X '/usr/bin/scp -R /var/.audit/audtrail* remsrv:/var/.audit/audit-backup'"

The last line above creates a specific syslog entry and then copies audit logs to remsrv into /var/.audit/audit-backup directory whenever a new audit trail file is created.

The maximum size of the primary audit trail (log file) is based on observed monitoring of the activity on the server:

PRI_SWITCH=1000 (the size is in Kbytes)

6.  Start the auditing system, or reboot the server:

# /sbin/init.d/auditing start

7.  The entries in /var/adm/syslog/syslog.log look like:

audit system approaching AuditFileSwitch point.

current audit trail size = 905 kilobytes.

Use -X option to schedule a task at each switch point to archive and

backup current audit trail, and make sure file system not to become full.

audomon: auto-switch to /var/.audit/audtrail.20121022_1220 was successful.

audomon: auto-switch to /var/.audit/audtrail.20121022_1221 was successful.

8.  To check the current auditing status, after some activity on the server, it might look like:

# audsys

auditing system is currently on

current trail: /var/.audit/audtrail.20121022_1221

next trail: none

statistics- afs Kb used Kb avail % fs Kb used Kb avail %

current trail: 1000 703 30 12288000 5643048 54

next trail: none

auditing system is actively writing to 1 file(s)

# ps -ef | grep audomon

root 3151 1 0 12:04:08 ? 0:00 /usr/sbin/audomon -p 20 -t 1 -w 90 -o /var/adm/syslog/syslog.log

# ll /var/.audit

total 0

drwx------2 root sys 96 Oct 22 12:04 audtrail

drwx------2 root sys 96 Oct 22 12:20 audtrail.20121022_1220

drwx------2 root sys 96 Oct 22 12:21 audtrail.20121022_1221

The audit trails (binary log files) are automatically created once the maximum size/threshold is reached. There is no need to run a script or cron job for it.

6.  Disable HP-UX Auditing

To disable auditing on the system, follow these steps:

1. Stop system auditing using the following command:

# audsys -f

2. Set the AUDITING flag to 0 in the /etc/rc.config.d/auditing file to prevent the auditing system from starting when the system is rebooted.

3. (Optional) Stop the audomon daemon. One method:

# kill `ps -e | awk '$NFS~ /audomon/ {print $1}'`

7.  View Audit Logs

The audisp(1M) command will be obsolete in a future release. Invoking

/usr/sbin/auditdp -r audit_trail produces the same output as

/usr/sbin/audisp audit_trail.

The following options are available with the audisp command:

-f Displays failed events only

-p Displays successful events only.

-c system_call Displays the selected system call

-t Display events that occurred after the given time

-s Displays events that occurred before the given time

-u user-name Displays information for a specific user

-l terminal-name Displays information for a specific terminal

-e event-name Displays information for the given event

> file-name Writes output to specified file

It can take a few minutes to prepare the record for viewing when working with large audit logs. When viewing the audit data, be aware of the following anomalies:

• Audit data can appear inaccurate when programs that collect data for auditable system calls supply incorrect parameters. The audit data shows what the user program passed to the kernel. For example, calling the kill system call with no parameters produces unpredictable values in the parameter section of the audit record.

• System calls that take file name arguments may not have device and inode information properly recorded. The values will be -1 if the call does not complete successfully.

• Auditing the superuser while changing the event or system call audit parameters will result in a long audit record. For example, when you add an event type to be audited, a record will be produced for each event type and system call that has been enabled for audit, not just for the new event type being added.

Some examples of commands:

• Display the log output on the screen:

# /usr/sbin/audisp /var/.audit/audtrail/spu0.log

• Direct the log output to /tmp/mylogoutput:

# /usr/sbin/audisp /var/.audit/audtrail/spu0.log > /tmp/mylogoutput

• View successful events only:

# /usr/sbin/audisp -p /var/.audit/audtrail/spu0.log

• View activities owned by user newadm:

# /usr/sbin/audisp -u newadm /var/.audit/audtrail.20121022_1237

• View login events only:

# /usr/sbin/audisp -e login /var/.audit/audtrail.20121022_1220

The better command is auditdp(1M) in the newer versions of auditing. An example for login auditing:

# auditdp -r /var/.audit/audtrail.20121022_1220 -s "+event=login"

Example of exporting auditing trail to standard output and appending the same data into syslog:

# auditdp -r /var/.audit/audtrail.20121022_1220 -P -o follow -O sync | /opt/audit/AudReport/bin/audit_p2l | tee -a /var/adm/syslog/syslog.log

Example of exporting auditing trail to file /tmp/myfile:

# auditdp -r /var/.audit/audtrail.20121022_1220 -P -o follow -O sync | /opt/audit/AudReport/bin/audit_p2l >/tmp/myfile

8.  Web-Based Audit Reporting

Note that these scripts in /opt/audit/AudReport directory, depending on the version of the software installed on HP-UX servers, might need minor modifications!

Modify the Shell script /opt/audit/AudReport/bin/audreport_setup_web

# vi /opt/audit/AudReport/bin/audreport_setup_web

The following four lines had to be changed on my test server:

HTPASSWD_EXE=/opt/hpws22/apache/bin/htpasswd

APACHE_CTL=/opt/hpws22/apache/bin/apachectl

HTTPD_CONF=/opt/hpws22/apache/conf/httpd.conf

/sbin/init.d/hpws22_apache start

The original ones were:

HTPASSWD_EXE=/opt/hpws/apache/bin/htpasswd

APACHE_CTL=/opt/hpws/apache/bin/apachectl

HTTPD_CONF=/opt/hpws/apache/conf/httpd.conf

/sbin/init.d/hpws_apache start

Secondly, ensure that Apache web server is started:

# vi /etc/rc.config.d/hpws22_apacheconf

HPWS22_APACHE_START=1

Then, simply run:

# /opt/audit/AudReport/bin/audreport_setup_web

By default, the username to access the web reports is:

# cat /var/opt/audit/AudReport/.htpasswd

audreport_admin:Rd4heCHXvEWh2

# /opt/audit/AudReport/bin/audreport_generator

NOTE: HTTP_ALIAS is not specified. Assuming /audreport_web.

NOTE: REPORTS_FILENAME is not specified. Assuming index.html.

NOTE: REPORTS_LOCATION is not specified. Assuming /var/opt/audit/AudReport.

NOTE: STYLESHEETS_LOCATION is not specified. Assuming /opt/audit/AudReport/xslts.

NOTE: REPORT_STYLE is not specified for the report "passwd_change_history". Assuming audreport_generic.xsl.

NOTE: REPORT_STYLE is not specified for the report "user_account_history". Assuming audreport_generic.xsl.

NOTE: REPORT_STYLE is not specified for the report "file_ownership_change_history". Assuming audreport_generic.xsl.

Generating reports ......

Generated reports are now available at:

http://<hostname>/audreport_web/index.html

Here is a screenshot of a web-based report:

9.  General Guidelines for HP-UX Auditing

• Check the audit logs according to the security policy. For example, a

security policy might state that an online audit file should be retained for at least 24 hours and all audit records stored offline should be retained for a minimum of 30 days.

• Review the audit log for unusual activities, such as: late hours login, login failures, failed access to system files, and failed attempts to perform security-relevant tasks.

• Prevent the overflow of the audit file by archiving on a regular basis.

• Ensure that when the required data retention period has ended, the logs are retired by destroying them according to the organization's data destruction policies.

• Revise current selectable events periodically, especially after installing new releases of HP-UX, since new system calls are often introduced in new releases.

• Revise audited users periodically.

• Do not follow any pattern or schedule for event or user selection.

• Audit trails (binary log files) must never be part of root file system (/). Typically, they should be saved under /var.

• Set site guidelines. Involve users and management in determining these guidelines.

• If the audit data volume is expected to be high, configure audit trails on a logical volume consisting of multiple physical disks and multiple physical I/O cards. Use the -N option with audsys command to split the audit trail into multiple files.

• Frequently accessed data, such as production data, must be available on-line. Data not requiring as frequent or ready access such as back-up data can be stored off-line. Use the auditdp command to filter on-line data to remove unnecessary information. This enables you to keep the audit file at a manageable size and keep the less interesting information in off-line, backup storage. For example, use auditdp to filter only login and logout events from one month’s audit trail. If you need to access other records, you can recover them from off-line backup tapes.

• Ensuring the confidentiality, integrity, and availability of logs is very important:

Logging mechanisms must neither be deactivated nor compromised to

provide business continuity of logging services in the event of an

incident.

Ensure that log files cannot be edited or deleted. Generally only

administrators and auditors must have access to log files for review

and management only. All privileged user (the administrator and

auditor) access must be logged and reviewed thoroughly and frequently by others outside that user domain.

Communications must be protected with mechanisms such as encryption

(for example, HP-UX IPSec and SSL).

Protect the confidentiality and integrity of log files using either

message digests or encryption or digital signatures.

Provide adequate physical protection for logging mechanisms and

stored logs by preventing unauthorized physical access.

Page 1