Unless otherwise noted, articles © 2005-2008 Doug Spencer, SecurityBulletins.com. Linking to articles is welcomed. Articles on this site are general information and are NOT GUARANTEED to work for your specific needs. I offer paid professional consulting services and will be happy to develop custom solutions for your specific needs. View the consulting page for more information.


Solaris/BSM Logging

From SecurityBulletins.com

Jump to: navigation, search

Contents

Centralized BSM C2 Auditing to improve Solaris Security.

(c) 2003 Doug Spencer Written 8/24/03

An often overlooked security tool is included free with every recent copy of Solaris. It is the Basic Security Module (BSM) that provides C2 auditing capabilities. By design, BSM writes logs in a binary format, normally dumping them in /var/audit. Many commercial tools, such as ISS RealSecure, are little more than front-ends to BSM.

Utilizing some free tools, you can provide a fully Unix based, comprehensive framework for monitoring your Solaris system security. The Tools

  • Sun Solaris
  • Stunnel from www.Stunnel.org
  • Syslog-NG from http://www.balabit.com/products/syslog_ng/

    Introducing BSM

    BSM is included with Solaris 2.3 and above. It provides the ability to monitor files, devices, user interaction, process actions, system calls, and most anything that occurs in Solaris. Ever had a user delete a file and deny they deleted it? BSM can provide the ability to store a user's actions in a way they can't edit, unlike the shell history.

    Installing and Configuring BSM

    Installing BSM is fairly easy. It requires the following Solaris Packages:

  • SUNWcar - Core architecture
  • SUNWcsr - Core (root)
  • SUNWcsu - Core (user)
  • SUNWhea - Header files
  • SUNWman - Online manual pages(optional) Once you have the required packages, doing an basic install of BSM requires you only type 'cd /etc/security && ./bsmconv' as root and reboot to load the new /etc/system parameters. Note that enabling BSM by default disables the Stop-A or Break-A sequence to get to the OBP (the 'ok> ' prompt). This makes good sense from a security standpoint and also prevents a server from going down when a terminal is unplugged from the serial port. If you don't like this action, you can comment the line 'set abort_enable = 0' in /etc/system. After the reboot, check that auditd is running ('ps -ef | grep auditd' will tell you). If it is running, then we can continue with our configuration. If not, try running /usr/sbin/auditd or check the system logs for errors. Next, edit /etc/security/audit_startup and add a new line 'auditconfig -setpolicy +argv' if it doesn't already exist. This tells BSM to log arguments a call and is useful because it allows you to see exactly the command that was executed. To save shell commands and script executions, edit /etc/security/audit_control and add 'flags: lo,ex' to track logins, and exec() calls. This will track all commands run by a user or a shell script system-wide. Restart BSM by running '/etc/init.d/auditd stop && /etc/init.d/auditd start' You should now see files being created in /var/audit. If you now run 'tail -f `cut -f2 -d: /etc/security/audit_data` | praudit -l' you will see a running display of execs and login information for this server. If that works, you've done everything right so far.

    Introducing Stunnel

    Stunnel provides the ability to tunnel TCP traffic through an SSL encrypted transport. It provides authentication using SSL certificates, and does not require a user account that can be remotely accessed like SSH tunnelling would. Compiling Stunnel is easily accomplished using OpenSSL and the GCC compiler. Simply follow the directions that come with Stunnel to compile and install it.

    To configure Stunnel with the 4.x version, edit the stunnel.conf file. For our purpose, we will have one central repository server that is accepting inbound connections, and numerous clients that will initiate connections. Current versions of Stunnel allow you to specify either client or server mode, not both. To get around this limitation, simply start two Stunnel processes, specifying a specific configuration file for each.

    The client will have a configuration similar to the following:

    # Based on Sample stunnel configuration file
    # Copyright by Michal Trojnara 2002
    
    cert = /stunnel/etc/stunnel/stunnel.pem
    chroot = /stunnel/var/run/stunnel/
    # PID is created inside chroot jail
    pid = /stunnel.pid
    setuid = nobody
    setgid = nogroup
    
    #Verify = 3 requires the peer certificate to be distributed
    verify = 3
    CApath = /certs
    
    # Use it for client mode
    client = yes
    
    # Accept only from the loopback interface and direct traffic to 
    # the logserver's stunnel listening on 1514.
    [syslog]
    accept = 127.0.0.1:1514
    connect = logserver:1514
    
    The server will have a configuration similar to the following:

    # Based on Sample stunnel configuration file
    # Copyright by Michal Trojnara 2002
    
    cert = /stunnel/etc/stunnel/stunnel.pem
    chroot = /stunnel/var/run/stunnel/
    # PID is created inside chroot jail
    pid = /stunnel.pid
    setuid = nobody
    setgid = nogroup
    
    #Verify = 3 requires the peer certificate to be distributed
    verify = 3
    CApath = /certs
    
    # Use it in server mode
    client = no
    
    # Accept only from the loopback interface and direct traffic to 
    # the logserver's stunnel listening on 1514.
    [syslog]
    accept = 1514
    connect = 127.0.0.1:514
    

    Next, generate the certificates using OpenSSH. This process is just like any SSL certificate. The certificate can be self-signed, or signed by a third party, depending on your security policy. In general, the command is:

    openssl req -x509 -newkey rsa:1024 -keyout stunnel.pem -out stunnel.pem

    Once you have a PEM file, put the public key from the each client into the server's /stunnel/var/run/stunnel/certs directory. Run ca_rehash from the Openssl suite. Make sure the public certificate is chmod 444, since it will be read as the user specified in the configuration file, nobody/nogroup in the files shown above.

    Introducing Syslog-NG

    Syslog-NG is a replacement for the standard, plain Syslog. It runs on a variety of different Unix systems, including Solaris. It can be compiled for Solaris using GCC with only very minor changes to the configuration file in the version I have used. Follow the instructions that come with the current version of Syslog-NG to compile it.

    Once you have Syslog-ng compiled and installed, you will need to configure it so it can send informatin to your central repository via an encrypted Stunnel connection.

  • Personal tools