Over on his blog at Sun Glen Brunett has announced he’s published a new version of the Solaris 10 Deep Dive security training. He’s updated it to cover new features and tools available in the latest 10/09 release of Solaris 10.
The updated Deep Dive includes things like nss_LDAP support for shadowAccount, ZFS quotas, and an example of using the Solaris Trusted Extensions. As usual it’s well written and aims to expose a huge amount of technology very quickly – so grab a copy and have a read through.
You can grab the PDF here or the OpenOffice version here.
Glenn’s blog at Sun is well worth subscribing to to keep on top of general security issues and discussions, and if you like the latest Deep Dive update be sure to drop him a line.
Logfile management has long been a bane for sysadmins everywhere. Applications seem to scatter logfiles all over the place, and they grow at an alarming rate. We want the information in them, so we need to cycle and compress them. Previously this involved writing custom scripts that can handle the logfile management and restarting the application – and to add to the pain, these scripts had to be tested, deployed, and monitored.
Luckily Solaris comes with a handy utility called logadm, which is used by the OE to manage some of the core system log files. logadm can quickly and easily be used to handle all of our log file managment needs.
Let’s look at two log files which aren’t handled by Solaris out of the box – sulog and wtmpx. Both are important, as they help us with our user access audit trail. For starters, we want to keep two old copies of each, and we want to cycle them every two weeks.
Our logadm syntax looks like this:
/usr/sbin/logadm -C 2 -p 2w -c -w <full_path_to_logfile>
- -C number of copies to keep
- -p time between each log cycle (2 weeks)
- -c copy and them truncate (doesn’t need to restart a service then)
- -w writes an entry into /etc/logadm.conf for this log file
So executing the following:
bash-3.00# logadm -C 2 -p 2w -c -w /var/adm/sulog
bash-3.00# logadm -C 2 -p 2w -c -w /var/adm/wtmpx
will result in the following two lines being written to the end of /etc/logadm.conf
/var/adm/wtmpx -C 2 -c -p 2w
/var/adm/sulog -C 2 -c -p 2w
Getting logadm to add an entry to /etc/logadm.conf means that this won’t be a one-off thing – each time logadm executes from cron, it will read the entries from this file. Each entry is checked to see if the log file’s size or age means it’s due for rotation.
wtmpx is obviously a binary file that’s used by last – rather than having to restart the utmpd daemon, it’s easier to just truncate the file. last can still read the older copies – just use the syntax
last -f <wtmpx_file>
It’s important to properly cycle wtmpx, rather than just deleting or truncating it, because it provides a helpful audit trail of users who accessed the system – showing when they logged in, and from where.
This is great if we just want to cycle logs around – but what if we want to compress them as well? Apache is the poster child for log generation – it spits out copious amounts of data, and you want to keep it all for analysis, but it’s a pain to manage.
On my test machine I’ve deployed Apache via Blastwave, so it’s logging to /opt/csw/apache2/var
With SSL enabled there are five log files that I’m interested in:
bash-3.00# ls -l
total 31536
-rw-r--r-- 1 root other 5400214 Oct 30 16:26 access_log
-rw-r--r-- 1 root other 8716843 Oct 29 23:18 error_log
-rw-r--r-- 1 root root 760298 Oct 30 16:26 ssl_access_log
-rw-r--r-- 1 root root 268873 Oct 30 16:26 ssl_error_log
-rw-r--r-- 1 root root 934541 Oct 30 16:26 ssl_request_log
We can just modify the previous logadm command to handle wtmpx – but what about the compression? Helpfully logadm will automatically compress cycled log files using gzip, if we pass it the -z flag. -z will also take a count option, which tells logadm to leave the most recent logfiles uncompressed.
In this case, however, we want everything except the current in-flight log file compressed, and we want to cycle when the logfile reaches 10mb is size:
bash-3.00# logadm -C 10 -s 10m -c -z 0 -w /opt/csw/apache2/var/log/access_log
logadm drops an entry into /etc/logadm.conf for us:
/opt/csw/apache2/var/log/access_log -C 10 -c -s 10m -z 0
Add an entry for each of the five log files, and we end up with this in /etc/logadm.conf:
/opt/csw/apache2/var/log/access_log -C 10 -c -s 10m -z 0
/opt/csw/apache2/var/log/error_log -C 10 -c -s 10m -z 0
/opt/csw/apache2/var/log/ssl_access_log -C 10 -c -s 10m -z 0
/opt/csw/apache2/var/log/ssl_error_log -C 10 -c -s 10m -z 0
/opt/csw/apache2/var/log/ssl_request_log -C 10 -c -s 10m -z 0
Using a combination of log cycling and compression, logadm can handle pretty much any application’s log files for us. By using copy and truncate as well, we aren’t forced to restart each application when we cycle the logs, which ends up giving us a huge amount of control over our log files, without having to write and maintain shell scripts.
We’ve all been there – there’s a missing binary or library on a Solaris host, someone’s accidentally deleted it, and we need to re-install the package. Or the other common scenario – two boxes that have been built by hand, one has binary A and the other doesn’t – which package adds it?
Along with the usual Solaris package management commands of pkgadd and pkgrm, there’s a lesser known utility called pkgchk. pkgchk allows us to check which package a file belongs to.
pkgchk will work with binaries:
-bash-3.00$ /usr/sbin/pkgchk -l -p /usr/bin/less
NOTE: Couldn't lock the package database.
Pathname: /usr/bin/less
Type: regular file
Expected mode: 0555
Expected owner: root
Expected group: bin
Expected file size (bytes): 117760
Expected sum(1) of contents: 20724
Expected last modification: Jan 23 01:48:30 2005
Referenced by the following packages:
SUNWless
Current status: installed
And we can also invoke pkgchk for libraries as well:
-bash-3.00$ /usr/sbin/pkgchk -l -p /lib/libresolv.so.1
NOTE: Couldn't lock the package database.
Pathname: /lib/libresolv.so.1
Type: regular file
Expected mode: 0755
Expected owner: root
Expected group: bin
Expected file size (bytes): 48368
Expected sum(1) of contents: 5063
Expected last modification: Jan 23 01:44:54 2005
Referenced by the following packages:
SUNWcslr
Current status: installed
For a quick overview of some of the other options, just invoke pkgchk with the -? command line:
-bash-3.00$ /usr/sbin/pkgchk -?
usage:
pkgchk [-l|vqacnxf] [-R rootdir] [-p path[, ...] | -P path[, ...]]
[-i file] [options]
pkgchk -d device [-f][-l|v] [-p path[, ...] | -P path[, ...]]
[-V ...] [-M] [-i file] [-Y category[, ...] | pkginst [...]]
where options may include ONE of the following:
-m pkgmap [-e envfile]
pkginst [...]
-Y category[, ...]
As you can see from the output, pkgchk is also very handy to see if the binaries or libraries that were part of a Solaris package file have been overwritten. As each file in a package has it’s checksum, file size, ownership, and permissions stored as part of the package manifest, this gets added to the Solaris package database when the package is installed – giving a quick and easy method to sanity check your installation.
Having covered how to manually configure ethernet interfaces in Solaris, I’ll now go over configuring the DHCP client. Solaris comes bundled with both a DHCP client and server, but here we just want to configure the client to go out and configure a Solaris ethernet interface.
Instead of a hostname.<interface> file, you need to create two empty files – dhcp.<interface> and hostname.<interface>, in the /etc/directory
bash-3.2$ touch /etc/dhcp.e1000g0
bash-3.2$ touch /etc/hostname.e1000g0
Reboot for the changes to take effect.
NOTE: you can have either DHCP or a static IP address – so double check which files are in place under /etc and what their contents are.
DHCP can be checked with the following commands:
bash-3.2$ /usr/sbin/ifconfig e1000g0 dhcp status
And you can release the DHCP lease with:
bash-3.2$ /usr/sbin/ifconfig e1000g0 dhcp release
DHCP from within VMWare will allocate a default router and DNS settings automatically to your Solaris VM. To enable this to work properly, both /etc/defaultrouter and /etc/resolv.conf must be present, but empty.
If these files already exist, just delete them:
bash-3.2$ rm /etc/defaultrouter
bash-3.2$ rm /etc/resolv.conf
Then recreate them as empty files with the touch command:
bash-3.2$ touch /etc/defaultrouter
bash-3.2$ touch /etc/resolv.conf
Now reboot and note the new settings take effect.
Recently I’ve had several clients who’ve just started with Solaris, and who have had roughly similar questions. So I thought I’d put up a few “How To” posts covering some Solaris basics.
Each LAN interface in Solaris has a configuration file in /etc which is named after the interface name and it’s instance.
So, let’s assume that you have two e1000g interfaces configured – you’d have two configuration files:
/etc/hostname.e1000g0
/etc/hostname.e1000g1
These files will just contain a hostname, which maps to an entry in /etc/hosts.
An example from my OpenSolaris development workstation:
bash-3.2$ cat /etc/hostname.e1000g0
grond
And this is /etc/hosts:
# Internet host table
#
::1 grond grond.local localhost loghost
127.0.0.1 localhost
192.168.13.100 grond grond.local loghost
When Solaris boots, all it does to configure a LAN interface is look for hostname.* files in /etc. It then looks up the hostname in /etc/hosts to find out the IP address, then configures the interface.
So if you need to change the IP address of a LAN interface in Solaris, all you need to do is edit the hostname entry in /etc/hosts and reboot. For example, to change grond’s e1000g0 IP address to a different subnet, /etc/hosts would be modified to:
# Internet host table
#
::1 grond grond.local localhost loghost
127.0.0.1 localhost
192.168.125.100 grond grond.local loghost
Then reboot the host for the changes to take effect.
