fixsolaris.txt Version 8.0
Copyright (c) 1998-2001 Christopher A. Petro.
petro@christopherpetro.com
http://www.christopherpetro.com/
This document may be distributed freely so long as it is distributed
in its entirety, unmodified. Non-commercial use of portions of it and
the ideas contained in it is allowed so long as credit is given. If
you wish to republish the content of this document commercially,
please contact the author at petro@christopherpetro.com.
ABSTRACT
--------
The following document is a summary of what I do when I get my hands
on a new Solaris box. It works well for me. It may not work well for
you. You might make a mistake following the instructions in here and
break your machine. I might feel sorry for you, I might laugh at you,
but I won't be liable for any damage you cause. This guide is meant
as a collection of friendly advice for other system administrators and
comes with no warranty whatsoever. Anything you do based on my advice
you do of your own accord and at your own risk.
If you have suggestions, things to add or constructive criticism,
please email them to me at petro@christopherpetro.com. If you don't
like this at all and think Solaris is just fine the way it
comes... Well, just make sure your firewall doesn't let anything
through. If you think that Solaris sucks and Debian r00lz, please
don't bother emailing me to explain how much better apt-get is than
pkgadd.
This covers Solaris 8/SPARC. Most of this will apply to x86 as well,
but I couldn't tell you exactly where it differs. The previous
version of fixsolaris, which applies to 2.6, is still available. The
original version, which applied to 2.5.1, is long gone and will never
be seen again.
INTRODUCTION
------------
I know that a lot of people disagree with me, but I feel that Solaris
is a Good Thing. It has a really good kernel, and scales very well.
It has excellent support from third-party software vendors. I also
love Sun hardware, and Solaris is currently the only thing I've seen
do Sun hardware justice.
Nonetheless, Solaris 2.5.1 came out of the box quite broken. There
were brain- dead permissions on files. Several of the basic UNIX
utilities were broken (most of those had been broken since at least
2.3). Every version, Sun managed to introduce some mind-numbingly
stupid bugs into a few key applications that gave anyone on your
system access to root privileges.
Because of my love-hate relationship with Solaris, I started fixing
it. For a while, I was just keeping track in my head of what to do.
Eventually, the number of things I was trying to remember became too
much for my mediocre mind, and I decided I needed to document the
process. I figured as long as I was doing that, I might as well make
it presentable and release it so that other people could enjoy Solaris
as Sun should have released it :^)
Thus was fixsolaris.txt v0.5 born. After receiving many, many
complaints from the 5 or 6 people I showed it to I decided to fix it
up. First I just added URLs as requested but eventually, after
Shawn Holwegner complained about the grammar in a few of the
sentences, I rewrote the whole thing. Thus was fixsolaris.txt v1.0
born.
This new and improved version included URLs for all software mentioned
in it. It featured improved grammar and was composed largely of
complete sentences. The commentary was wittier, the metaphors more
colorful, and the apostrophes far more lively.
Alas, Solaris 2.6 grew old, and I was publicly mocked for still using
it. My 64-bit processors were wasted on it. So I finally caved in
and installed Solaris 8. Fixsolaris 8 is now being released, just in
time for it to be made obsolete by the next release of Solaris.
Hopefully I'll update this document more quickly next time. :)
This document is still not ready for a complete novice to follow along
with it, and probably never will be. If you're a complete novice,
you should go buy some good books and graduate to the level of
"mostly competent admin" before you try and modify the OS like
this. It's quite possible to lock yourself out of your system if
you don't know what you're doing.
If you find any typos or errors, PLEASE email me. I had
/etc/nsswitch.conf written as /etc/nisswitch.conf for quite a while
and no one pointed it out to me. Don't assume someone else already
let me know.
INSTALLATION
------------
First of all, find yourself a nice relaxing chair. The installation
takes a while. Get yourself a coke, and use the Installation CD as a
coaster. You won't ever need it. You might not want to actually
destroy it, but there's no reason to boot off it. The Solaris
installer you know and love is actually located on the Software 1 CD.
Boot off that, and save yourself the frustration of dealing with the
strange beast on the Installation CD.
When you set up your name service options, you'll probably choose DNS.
If your network is like most, there's a good chance that your DNS
servers aren't on the local network segment. If this is the case, the
installer will sit for several minutes trying to look up an address
for the hostname you assigned. After that, it will complain about
failing to look up the hostname, and will give you the option of
continuing or modifying your settings. The solution to this whole
mess is to simply open a command tool (right click on the root window,
choose Utilities > Command Tool) and add a default route after you
assign the IP address but before you set the resolver settings. The
correct command will look something like:
route add default a.b.c.d
I used to have a list of the the minimum packages you could install to
have a functional system with headers and libraries in fixsolaris.
However, I don't run Solaris on really small systems anymore. On a
machine with a 4GB system disk, the half gig of disk space I would
save isn't really worth the time spent futzing with installation
options. A 75MB working install of Solaris 2.6 with development
headers and libraries was impressive, but I honestly don't care
anymore.
If you wish to install Solaris 8 with absolute minimal disk usage,
start with the Core System Support option, hit customize, and start
hacking bits out. You'll also want to make sure you add support for
all of the headers files and libraries you want. Some of the
subsystems, such as lp, are scattered across multiple clusters, so it
can take a few tries. If you work out a good minimum install, feel
free to email it to me, and I'll add it to this document.
For most users, I would recommend doing an "Entire Distribution"
install. The chances are good that the 1GB of disk space isn't going
to kill you on a modern system, and you never know when you might want
some toy that was included in an obscure-sounding software cluster.
This will leave your system with a lot of unneeded software running
after the first boot, but we'll take care of that in a few minutes.
You might want to install the "Sun4u FLASH PROM update generic
utilities" clusters if you have an UltraSPARC. Even if you've got the
version of the PROM included on the CD, Sun might release new versions
and the package could come in handy. If your system needs a flash
update to run Solaris 8, the installer will probably complain about
your update jumper not being set correctly. You'll have to open the
machine, reset the jumper, and try again.
DISK SLICES
-----------
One important consideration is the allocation of disk slices. It's
certainly possible to install a system with a single partition mounted
on /. However, this can cause all sorts of problems. There are good
reasons to split up your disk, and I'll mention a few of them here.
First, the root partition. This partition is critical to booting the
system. If the root partition cannot be mounted read-only
successfully, the system will simply hang. I haven't intentionally
sabotaged a Solaris 8 machine to find out what the exact behavior, but
in 2.6 it would just stop without even issuing any sort of message.
To fix this, you need to get physical access to the machine and boot
off another disk, cdrom, or the network and fsck the root partition.
Because you never want this to happen, you should make sure that
nothing which receives frequent updates is on the root partition. If
you do not create an /opt slice, you should probably move /opt to /usr
and set up a symbolic link. When you edit files on /etc, you should
sync to help make sure the file system will not be left in an
inconsistent state if the machine experiences an abnormal shutdown.
I generally make my root slices about 120MB. That's larger than they
need to be, but it never hurts to have a little extra room. If you're
setting up a system that has a lot of disk space, or one that can
never be taken down for maintenance, you might want to make it even
larger.
In order for the root partition to be fscked and remounted read-write, the
system needs to be able to run fsck. Generally this isn't a problem, but
because of the way some of the system binaries are installed, it can be.
Let's take a look at /sbin/fsck...
ls: /sbin/fsck: cannot open file: No such file or directory
GAK! It's not there. It's actually in /usr/sbin/fsck, which means
that Solaris needs to mount /usr before it can fsck the root
partition. Now, /usr is the sort of partition that's likely to get
updated a lot, and therefore is likely to not mount cleanly during
boot. This means that if /usr won't mount, not only can Solaris not
fsck the root partition, it can't even fsck /usr to clean it up enough
to mount it read-only.
So, what can we do? My first thought was to put fsck in /sbin and
modify the boot scripts to call it from there during boot. If /usr
failed to mount correctly, we could fsck it and try again. It sounded
like a great idea, but take a look at this:
mankind:~ % ldd /usr/sbin/fsck
libdl.so.1 => /lib/libdl.so.1
libc.so.1 => /lib/libc.so.1
/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1
fsck, and indeed most of /usr/sbin and /sbin, is not actually a static
binary. We could certainly copy those libraries into the root as
well, but fsck just calls /usr/lib/fs/ufs/fsck.
mankind:~ % ldd /usr/lib/fs/ufs/fsck
libc2.so => /lib/libc2.so
libadm.so.1 => /lib/libadm.so.1
libc.so.1 => /lib/libc.so.1
libelf.so.1 => /lib/libelf.so.1
libdl.so.1 => /lib/libdl.so.1
/usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1
At this point, I gave up. I swear that at some point I'll work out
exactly what I need to do to make the Solaris boot process more
reliable. When I do, I'll include a nice script here to patch the
boot scripts and move the necessary files into the root. Until then,
do be careful that you don't leave /usr in a dirty state very often.
You might want to make /usr/local a seperate partition if you install
things there often.
In case someone from Sun is reading this and wants to take up the
challenge of fixing this nonsense, I'll include my thoughts on how
this SHOULD be done.] In my mind, the most effective thing for Sun to
do would be to set up a /boot partition with the kernel and all the
static binaries needed to bring the system up. This partition would
only be mounted read-only during normal system operation, and would be
mounted read-write only long enough to make changes to software and
configuration files installed there. This can't really be the root
partition itself, because /etc needs to be modified frequently.
Once the software on /boot has insured that / and /usr are clean, the
boot could proceed more or less as it does now. This actually
requires mounting /boot as a dummy root and then mounting the real
root once it has finished it's work. I think the benefit of would be
immense, however. I can't count how many times I've had to drive to a
colo facility at 2am to fsck / or /usr and reboot a machine. The idea
that a rather stable system like Solaris can be so easily crippled and
rendered unbootable by a simple power failure is frustrating, and a
little embarassing.
The risk of instability during the boot process is nearly eliminated
if you enable logging on your file systems. This is discussed in the
section on /etc/vfstab below. This doesn't excuse Sun's poor
planning, but it can prevent it from causing problems for you.
The /usr partition itself should probably be fairly large. Solaris
itself installs a lot here. If you do not have a large disk, you may
wish to make a very large /usr, let /usr/local live on it, and symlink
/home to /usr/home. This makes the most space available to both
/usr/local and /home, though it sacrifices some security and
stability.
I build all of my new software in /usr/local, which I make a separate
partition when possible. This means that you can reinstall the OS
(letting it format /usr) without destroying everything you've built in
/usr/local. It also means that if you're really paranoid you can
mount /usr read-only, and possibly mount /usr/local nosuid.
I generally symlink /opt to /usr/opt and let /opt-style packages
install themselves there. Trying to guess ahead of time how much of
your software will go in /usr and how much in /opt is frustrating and
rarely yields good results.
Most of you have probably heard the old recommendation that your swap
should be at least twice the size of your physical memory. I'm not
going to explain why that rule of thumb made sense, but it's really
not that cut and dry. There are many things to take into
consideration, including the type of software running on the system,
the number of different programs running on the system, and the
physical memory in the system. Personally, I tend to provide between
one and two gigabytes of swap. For certain applications I might make
swap a few times larger than that.
A few commonly suggested guidelines are:
0.5 * physical RAM over 1GB
2 * Oracle SGA, if running oracle
I also like to make sure that the physical ram + swap is at least 2GB,
even for a workstation.
The /var partition is quite important. Your logs go in /var/log, and
some temporary files are stored in /var/tmp. This makes a root
mounting failure more likely than not after a power loss or kernel
panic. Also, because your logs go here and you don't want to risk
losing log data, you should make this fairly large. I generally make
/var 200-400MB, depending on the log volume the system will generate.
If you have sufficient slices available, you may wish to make /var,
/var/log, and /var/tmp all separate. This protects /var/log from
being filled by bogus additions to /var/tmp. /var still needs to be
separate from / in this case because it is updated so frequently by
running applications. If you wish to store your mail in /var/mail,
you will definitely want to have a dedicated slice for this, or
relocate it and replace it with a symlink (see below).
The /export/home partition that, by default, consumes the remaining
portion of your disk is related to nfs exporting and the automounter.
Personally, I don't really care for the automounter unless I'm
building a whole NIS+/NFS network with a lot of workstations and
users. If you're installing a standalone server or workstation, you
probably want to kill this and make a normal home volume somewhere.
Because the automounter lives on /home by default, you'll have to kill
it to get access to a partition on /home (see below).
BASIC TASKS
-----------
Before you delve into any major surgery on the system, you should go
ahead and set up the basic stuff. First of all, install the latest
recommended patch set from Sun. If you have Sunsolve access (you
really should purchase support if not), check the patches not in the
recommended set and install any that are important to you or fix
security problems. Get the patches at http://sunsolve.sun.com/.
Click on the "Patch Access" button.
Edit /etc/default/login and /etc/default/su. The first controls
several things that happen during login, and the second when you su.
Set the default UMASK here if you don't like the default of 022. Make
sure the CONSOLE= line in /etc/default/login is uncommented if you
want to prevent root logins from remote terminals.
You can modify PATH and SUPATH variables in these files to set
system-wide default paths. These paths are assigned before any
.profile or .login files are executed. Note that there is a different
path for the superuser in each case. These paths should not include
the current directory (.), to avoid accidental execution of trojan
scripts. In fact, you may not want to modify the default paths here
at all for security reasons. If you do, make sure that it does not
include paths in which users or attackers might be able to install
software.
Kudos to sun for finally allowing you to set DNS servers during
install. Hopefully the default gateway will be the next thing they
add to the installation dialog. Put the IP address of your default
router in /etc/defaultrouter. You can add it manually during your
first boot with a command like the following:
route add default 192.168.1.1
Edit /etc/syslog.conf. Sun has changed this since 2.6, but it's still
not right. Auth messages are still not logged to a file, and I really
prefer to have everything in /var/log. Be sure to note the usage of
the new /dev/sysmsg device. If you're using the consadm stuff, you'll
want to use it instead of /dev/console. This is important if you want
to know when people are trying to break into your system. This is
what I'm currently using:
kern.notice;auth.notice /dev/sysmsg
kern.notice;daemon.notice /var/log/messages
auth.none;mail.none;news.none;*.err /var/log/messages
auth.info /var/log/authlog
auth.notice /var/log/authlog
mail.info /var/log/maillog
news.info /var/log/newslog
news.none;*.alert root,petro
news.none;*.emerg *
Note that according to the man page, "A configuration entry with a
level value of notice must appear on a separate line." You may want
to forward important messages to a remote loghost, in case they are
lost in a system crash or the machine is compromised. See the sample
syslog.conf and the man page for information on how to do this.
Edit /etc/hosts and add any hosts whose names always need to be
resolvable. Also add the hostnames and IP addresses of all the
interfaces the machine will have.
Solaris supports multiple virtual network interfaces per physical
network interface. These are indicated by a colon and a number
following the physical interface name. For example, if you have a
happy meal ethernet, your physical interface is hme0. Virtual
interfaces can be created on this as hme0:1, hme0:2, etc. The
numbering does not need to be sequential; you might want to number
them based on the last octet of the address to make them easier to
find.
Create a file named /etc/hostname. for each interface. For
instance, /etc/hostname.hme0:1 for the interface hme0:1. The contents
of this file need to be the hostname whose IP needs to be assigned to
this interface. This will be looked up in /etc/hosts. To create a
virtual interface manually, use a command like the following:
ifconfig hme0:1 plumb 192.168.1.12 netmask 255.255.255.0 up
Similarly, use ifconfig with the unplumb parameter to remove such an
interface.
Edit /etc/netmasks to set the netmasks of the networks on which your
host has interfaces. Note the comment at the top about it being
limited to class A, B, and C addresses. In reality, it's not. If it
was actually classful, there wouldn't be a need for netmasks at all.
I think what Sun meant is that it doesn't support VLSM. In other
words, you can't set the subnet mask of 192.168.1.0 to 255.255.255.240
and the subnet mask of 192.168.1.128 to 255.255.255.192 in an attempt
to divide 192.168.1.0 into 8 blocks of 16 addresses and two blocks of
64 addresses. If you want to do this sort of stuff, you'll have to
make startup scripts to ifconfig the interfaces yourself.
Change TCP_STRONG_ISS in /etc/default/inetinit if you want to change
the TCP sequence number generation. You probably want this set to
2.
Edit /etc/default/cron. CRONLOG controls whether all cron actions are
logged. It's on by default, which may generate more logs than you
want. You can also specify PATH and SUPATH for cron jobs in this
file. Be careful, especially with SUPATH. If you want to limit who
can run cron/at jobs, put the users who need access in the following
files
/etc/cron.d/at.allow
/etc/cron.d/cron.allow
Optionally, you can exclude specific users by not having *.allow
files and instead listing excluded users in the following files
/etc/cron.d/at.deny
/etc/cron.d/cron.deny
[The at man page refers to these files in /usr/lib/cron, which is a
symlink to /etc/cron.d]
If you want to share things via NFS, put the share commands in
/etc/dfs/dfstab. Be sure to set sane permissions on the shares. See
below for more cautionary advice about using NFS. If you are using
NFS, you may want to add the following line to /etc/system as well:
set nfssrv:nfs_portmon = 1
This will provide some added protection since it will require NFS
clients to connect from privileged ports. If all of your authorized
clients are UNIX boxen or otherwise implement privileged ports and
they are reasonably secure, this will help stop people from making
unauthorized connections to the NFS server. On the Internet at large,
this offers no protection (but I'm sure you'd never allow NFS
connections from the Internet at large, right?).
Put your message of the day in /etc/motd, if you want one. Put a
login banner in /etc/issue, if you want one. You can create
/etc/default/telnetd and /etc/default/ftpd files with BANNER= lines to
display login banners on these services if you wish.
Edit the default profile in /etc/profile. This will be run by the
Bourne, Korn, zsh and bash shells at login, before a user's local
.profile. Add a MANPATH that points to any other manpage locations
you have. Make similar changes to /etc/.login for csh and tcsh users.
Contrary to advice given in earlier versions of this document, you do
not want to set LD_LIBRARY_PATH in these files. Setting it can cause
a lot of problems, because it overrides the compiled-in runpath in all
programs you run (more precisely, it's prepended to the list compiled
into the binary). It is far more effective to simply compile
applications using the correct runpath by setting LD_RUN_PATH or using
-R during the link step. In this way, if different applications all
require different version of a particular library (libdb, with it's
constantly changing interface, is a good example), they can all link
to the version they want.
When this fails is with programs that were not compiled with a correct
runpath. For example, a commercial product that uses Oracle may not
want to require customers to put the Oracle libraries in a specific
location and will instruct the user to set LD_LIBRARY_PATH to include
the directory in which the Oracle libraries are located. Another
common problem is the failure of Perl scripts; because perl scripts
are not compiled and linked into binaries, they do not contain a
runpath. Perl is not usually linked with Oracle's lib directory, and
installing DBD::Oracle later won't change this.
Both of these problems can be solved in far less risky manner, however.
If you modify the runtime linker's default search paths, you can add
these to the END of the list of library paths to be searched. This
will give you the same functionality in the two cases described above
while still allowing binaries to override these settings by including
a runpath. To do this, run the following command:
crle -l /usr/local/lib -l /usr/lib
substituting the appropriate directory name. This will set the default
search path for 32-bit binaries. To set the path for 64-bit binaries,
crle -64 -l /usr/local/lib/64 -l /usr/lib/64
By default these commands set the paths for ELF binaries. If you have
dynamically linked a.out binaries, use the -t AOT option to set the
search paths for these as well.
In both of these commands, MAKE SURE you include the original system
library path. If you do not, your system will be unable to run
anything dynamically linked, including crle. At this point feel free
to revisit my rant about important maintenance programs on Solaris
being dynamically linked.
If users will be working on the console of this system, you might want
to modify /etc/logindevperm. It controls the changing of ownership
and permissions on local devices during the login process.
Create ~root/.rhosts and /etc/hosts.equiv. Leave them empty, and
change the permissions to 000. Exploits which attempt to simply
write "+ +" to one of these files will fail with EPERM. Simply
removing them is not as strong.
Create /etc/shells and include all shells on the system, if you plan
to install new ones. See the getusershell(3C) man page for a list of
the shells which are allowed if you do not have an /etc/shells file.
Edit /etc/ftpusers to block access to the system by certain users.
Sun has finally started blocking root and most service users by
default, but you should add other service users such as httpd when you
create them.
Edit /etc/pam.conf and comment out the entries for r* services. It's
unlikely that these will be started if you've removed them from
inetd.conf, but it never hurts to be safe. If for some reason you're
allowing r* services, you probably want to remove the references to
pam_rhosts_auth.so.1 to prevent users from leaving their accounts (and
your machine) open to the outside world.
Edit /etc/vfstab. If you have a /home volume, you probably want to
set the options field (the last one) to "nosuid" to prevent users from
creating setuid binaries. Using this on / or /usr would be a bad
idea. If this system will not have a lot of changes on / or /usr, you
might want to set the options for these file systems to "ro". While
anyone who gets root access can remount the file system read-write, it
will certainly thwart a lot of attack scripts, rootkits and clueless
attackers. If you do this, you will need to remount the file system
rw to make changes.
Starting with Solaris 7, Solaris' ufs implementation supports logging.
This prevents the file systems from reaching an inconsistent state,
nearly eliminating the risk of problems that require fscking. To
enable logging on a partition, add logging to the list of options for
that partition. This feature is now very stable and works well on
both SPARC and x86. I'm not aware of any reason to not use it.
Solaris does not come with a windex database by default. Don't ask me
why. If you ask Sun and they answer, please pass their reply on to
me. Run the following to build the windex database:
catman -w
This will allow you to use man -k and friends to do keyword searches
on man pages. Run this command again to rebuild the database when you
add new man pages. To build pre-formatted versions of all your man
pages, run catman without the -w option. This will speed up man page
display on slow systems at the expense of some disk space.
An optional but often good step to take is to move root's home
directory. By default, all of root's files go in /, which is just
ugly, and can pose some risk. If you edit /etc/passwd and change
root:x:0:1:Super-User:/:/bin/sh
to
root:x:0:1:Super-User:/root:/bin/sh
and create /root with 700 permissions, you'll have a lot fewer files
and directories pile up in your / directory and keep people from
poking around root's files.
BASIC TOOLS
-----------
Now that you have a fully configured base Solaris installation, you
need to get some software installed on it. A computer without
software is hardly very useful. Solaris now includes a lot of extra
software it didn't used to, so this is much easier. Especially
welcome additions are traceroute and gzip. You'll want to browse
http://www.sunfreeware.com/ and pick up some more software, though.
NOTE: If you aren't sure how to do install packages, read the man page
or the documentation on www.sunfreeware.com. The basic procedure is:
1) gzip -d package.gz
2) pkgadd -d package
NOTE: While you're on www.sunfreeware.com, I'd recommend getting the
local versions of programs. SVR4 seems to enjoy having optional
software installed in /opt. Everyone else puts it in /usr/local, and
some software expects it to be there. It is also far easier to put
/usr/local/{bin,lib} in your PATH than to put 20 different
/opt/*/{bin,lib} paths in them. However, other than breaking software
that blindly assumes stuff is in /usr/local (one could argue that it's
already broken), there is no real problem with using the opt versions
of packages.
Now that you have gzip, you can install a C compiler. Get the gcc
package off of sunfreeware. Check for notes on the page about which
version of gcc to install. There have been problems with various
versions, and it is better to have an older, more stable version than
to have the latest C++ widgets and have none of your software compile,
or compile with bugs.
If the newest version of gcc on sunfreeware is not the latest
available and you know that the latest version is better, also
download the source code from the FSF site at
ftp://prep.ai.mit.edu/pub/gnu/gcc. Follow the INSTALL directions to
compile it.
You can also download a 30-day trial of Sun's excellent Forte C/C++
compiler from http://www.sun.com/forte/cplusplus/buy.html. It's
around 700MB, it's expensive and it's quite slow, but it produces some
excellent code. It also produces working 64-bit code. The only
version of gcc which produces 64-bit code right now is an old, buggy
version of egcs. I do NOT recommend using this version. Use gcc 3
and compile 32-bit, or use Forte.
Now that we have a working compiler, we can install some shiny new
software. A few of the things Solaris comes with are broken. Either
download the source code for these programs and libraries from
ftp://prep.ai.mit.edu/pub/gnu, or install them as packages from
sunfreeware.
ncurses
patch
tar
cpio
termcap
make (Solaris make isn't broken, but many programs require GNU make)
You might also want these additional toys. They're all on the FSF site.
gdbm
glibc
libg++
libstdc++
The following are not on the FSF site, but should also be installed to
replace the broken versions included with Solaris. You should be able
to find them at the site listed. They might also be on sunfreeware.
db (http://abyssinian.sleepycat.com/db/)
vim (http://www.vim.org/)
The following will give you better versions of some programs that
Solaris includes. Because the Solaris versions of these programs
work, you don't need to install them, but they are highly recommended.
They're also all on the FSF ftp site, and should be on sunfreeware as
well.
binutils
bison
fileutils
findutils
flex
gawk
grep
less
sed
You may also want to install some of the following, They are also all
on the FSF ftp site or www.sunfreeware.com. These are recommended but
not necessary.
screen (the single most useful piece of UNIX software out there. manage
virtual terminals, disconnect from and connect to them from anywhere,
connect from multiple locations, etc.)
emacs (for when you tire of showing off your manly vi skills and want to
actually get work done)
groff (print man pages in lovely postscript)
ispell (chek for speeling erors)
lynx (browse the web from a terminal session in an emergency, or all the time
if you hate yourself)
mc (like Norton Commander. very handy.)
perl (possibly the world's worst language, and probably the most useful)
You should definitely install some of the following as well. They're
not on the FSF site but you should be able to find them at the site
listed. Many of them are also on www.sunfreeware.com. Some of them
may have security risks associated with them, so be sure you
understand what the risks may be before installation.
top (this will let you view the processes using the most resources)
http://www.groupsys.com/top/
gated (if you do dynamic routing, get this. Solaris only supports RIP v1.)
http://www.gated.org/
tcp wrappers (if you to limit access to tcp-based services)
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz
ipfilter (this will allow you to protect services like RPC and NFS with ACL's
if you absolutely have to leave them enabled)
http://coombs.anu.edu.au/~avalon/ip-filter.html
apache (the world's most popular web server, with good reason)
http://www.apache.org/
samba (allows UNIX machines to act as Windows file, print, and domain servers)
http://www.samba.org/
openssh (secure shell. secure, encrypted rlogin replacement. a must have.)
http://www.openssh.org/
ytalk (if you or your users want talk, this is a very feature-filled
version of it)
http://www.iagora.com/~espel/ytalk/ytalk.html
proftpd (a solid ftpd replacement. recommended if you want to allow anonymous
ftp access.)
http://www.proftpd.org/
postfix (an excellent sendmail replacement. very fast and secure.)
http://www.postfix.org/
exim (another sendmail replacement. excellent, free online support.)
http://www.exim.org/
qmail (another sendmail replacement. I won't say anything else for
fear of retribution by the author.)
http://cr.yp.to/qmail.html
Of course, there are thousands of other programs you might want to
install. You can find almost all of them (and tens of thousands you
will never want to install) at http://www.freshmeat.net/.
LOCKDOWN
--------
Congratulations. You've now got a useful, working Solaris box. Now
it's time to clean it up. There are many evil things lurking on your
box. Try doing a ps -ef and see how many of the processes you can
identify, and how many of them you think you really need. There are
almost certainly several that you don't need.
Edit /etc/inetd.conf. You can comment out just about everything in
this file. The following are the services you may want to leave
enabled. The general rule is to remove anything you don't need. You
can always re-enable it later.
telnet (ssh would be better)
ftp (be sure to install proftpd or something else safe)
finger (you should probably install sfingerd instead of normal finger)
talk (you should probably install ytalk instead)
login/shell/exec (these are dangerous, but you might need them)
tftp (used by routers and such. be careful configuring this one)
kerbd (if you are using kerberos authentication)
rpc.ttdbserverd [RPC] (if you're running openwindows and/or CDE)
rpc.cmsd [RPC] (if you're running the CDE calendar program)
xaudio (if you're running sun X11 audio stuff on the console)
Several of the services listed above have been the source of major
security problems in the past, so be sure to limit access to them with
ipfilter and keep up with current security problems. If you don't leave
any inetd-spawned services enabled, you can disable inetd's startup
script entirely.
If you are using some RPC software (nfs, nis, or anything marked [RPC]
above), you will need to leave the RPC startup script enabled later
on.
Depending on what services you are running, you may wish to replace
inetd with xinetd. It provides much better access control and
logging. You can find xinetd at http://www.xinetd.org.
Install openssl (http://www.openssl.org/) and openssh
(http://www.openssh.org/). FTP and Telnet send passwords in plaintext
and are generally quite evil. Openssh supports ssh, ssh2 and sftp.
Install ProFTPD if you want to provide anonymous access. The SYSV one
doesn't provide enough control over anonymous access. Don't use FTP
for non-anonymous access.
When someone is attempting to break into a system, they will often
scan the machine to see what services are available on it. Klaxon and
Tocsin can be used to detect these port scans, and are both available
from http://www.eng.auburn.edu/~doug/second.html.
Install klaxon and add it to /etc/inetd.conf on some typical services
and some rarely used ones to catch portscans and attacks. For
example:
shell stream tcp nowait root /usr/local/bin/klaxid klaxon shell
login stream tcp nowait root /usr/local/bin/klaxid klaxon login
exec stream tcp nowait root /usr/local/bin/klaxid klaxon exec
supdup stream tcp nowait root /usr/local/bin/klaxon klaxon supdup
tcpmux stream tcp nowait root /usr/local/bin/klaxon klaxon tcpmux
tftp dgram udp wait root /usr/local/bin/klaxid klaxon tftp
echo stream tcp nowait root /usr/local/bin/klaxon klaxon echo
discard stream tcp nowait root /usr/local/bin/klaxon klaxon discard
chargen stream tcp nowait root /usr/local/bin/klaxon klaxon chargen
Install tocsin and create a script to start it at runtime. Hook it up
to some ports that should only show up on a portscan attempt. Example:
/usr/local/bin/tocsin tcpmux echo discard chargen supdup x400
Another tool to provide this sort of monitoring is PortSentry. You
can download it at http://www.psionic.com/abacus/portsentry. When
combined with their logcheck (http://www.psionic.com/abacus/logcheck)
product, the output is far more readable. These tools are also being
maintained. I would generally recommend them over klaxon and tocsin,
but I am not all that comfortable with their pending software patents
and restrictive licensing.
We can now start eliminating some of the software that is started by
Solaris at boot time. There is a set of scripts in /etc/init.d which
each take either a "start" or "stop" parameter. In the
/etc/rc{S,2,3}.d directories are links to the scripts in /etc/init.d.
These links are executed as the system enters the runlevel
described. Links which begin with "S" are passed a parameter of
"start", while links which begin with "K" are passed a parameter of
"stop". The order the scripts are started in depends on the number
following the S or K. If you need to stop services before shutdown
(such as Oracle), you'll want to add K links to your Oracle script in
/etc/rc{0,6}.d as well. Read /etc/init.d/README for a full
description of how this all works. If you want to make scripts that
react differently based on the previous runlevel, take a look at
/etc/init.d/uucp.
When a system comes up in runlevel 3, it will execute all scripts in
rcS.d, rc2.d, and rc3.d. It "passes through" the other runlevels on
its way to runlevel 3. This is NOT the same behavior as the SYS
V-style init included with Red Hat Linux.
You should go through the S links in each rc?.d directory and make
sure that unnecessary software is not being started. Links you do not
wish to execute can be renamed with a lowercase s, a preceeding _, or
whatever suits your fancy. I don't recommend removing them. If you
want to enable them later, it's nice to know what order they should be
started in. Which scripts you want to leave enabled will depend on
the system and what software is being run on it. For servers, I
generally leave only the following enabled:
rc2.d/S21perf
rcS.d/S30network.sh
rcS.d/S30rootusr.sh
rcS.d/S33keymap.sh
rcS.d/S40standardmounts.sh
rcS.d/S42coreadm
rcS.d/S50devfsadm
rcS.d/S70buildmnttab.sh
rc2.d/S01MOUNTFSYS
rc2.d/S05RMTMPFILES
rc2.d/S20sysetup
rc2.d/S69inet
rc2.d/S70uucp
rc2.d/S74syslog
rc2.d/S74xntpd
rc2.d/S75cron
rc2.d/S75savecore
rc2.d/S80PRESERVE
rc2.d/S88utmpd
rc2.d/S90volmgt
rc2.d/S99audit
If
cd /etc; ls rc*.d/S*
shows more scripts than this, make sure you want them running.
Things I rename include:
rcS.d/S10initpcmcia [i don't have pcmcia. i sold my SPARC Voyagers]
rcS.d/S35cacheos.sh [i don't generally use NFS]
rcS.d/S41cachefs.root [i don't generally use NFS]
rcS.d/S42ncakmod [i don't use NCA]
rc2.d/S47asppp [this is an evil pppd]
rc2.d/S71ldap.client [not generally used]
rc2.d/S71rpc [i don't generally have RPC services running on servers]
rc2.d/S71sysid.sys [learn to edit the config files already]
rc2.d/S72autoinstall [i don't plan to jumpstart after install]
rc2.d/S73cachefs.daemon [i don't generally use NFS]
rc2.d/S73nfs.client [i don't generally use NFS]
rc2.d/S74autofs [autofs is just annoying if you don't have a large network]
rc2.d/S75flashprom [do we really need to run this on every boot?]
rc2.d/S76nscd [this daemon sounds great but has caused no end of problems]
rc2.d/S80lp [i don't generally have lpd running]
rc2.d/S80spc [i don't generally have lpd running]
rc2.d/S85power [just what i wanted. APM for my SPARC.]
rc2.d/S88sendmail [i run postfix]
rc2.d/S89bdconfig [you might want this if you use B&D programs]
rc2.d/S90wbem [cute. scary.]
rc2.d/S93cachefs.finish [i don't use cachefs]
rc2.d/S94ncalogd [i don't use NCA]
rc2.d/S99dtlogin [i start x after login]
rc3.d/S15nfs.server [i don't generally run NFS]
rc3.d/S50apache [i build my own apache]
rc3.d/S76snmpdx [i don't generally use the SNMP services]
rc3.d/S77dmi [i don't use Solstice DMI]
If you need network printing, you might be prefer another lp system.
There are several available. The Solaris print system is quite nice,
though somewhat complicated. A port of the BSD lpd system to Solaris
is available at http://www.eng.auburn.edu/~doug/second.html. You
should also make sure that whatever lp system you use, limit access to
it to local systems via tcpwrappers or ipfilter.
Install a sane mail server. If you really, really must use sendmail,
install the latest one. I would recommend using something besides
sendmail, however. I use Postfix, but exim and qmail are other viable
options. A new, all-in-one mail system called Courier
(http://www.courier-mta.org/) is available. I have not used it, but
it seems to be under active development.
If you need to get mail remotely, install a POP3 and/or IMAP4 server.
The University of Washington system gets used a lot. You can get it
from ftp://ftp.cac.washington.edu/imap. If you use this one, be sure
to keep up with new versions, as it has been known to have some very
serious security problems (though nothing in recent years). There are
a few other options, such as qpopper (http://www.eudora.com/qpopper/)
and cucipop (ftp://ftp.fdt.net/pub/unix/packages/cucipop). Cucipop
works very well and is very fast. Cyrus
(http://asg.web.cmu.edu/cyrus/) is an excellent system which provides
POP3, IMAP4 and ACAP services and plugs into Postfix well. It doesn't
work with normal UNIX mailspools.
OpenWindows, Sun's version of the X11 Windowing System, has a lot of
extra features which are quite spiffy. It is also far faster than
free X servers on Sun's modern framebuffers. Despite these
advantages, DPS and other features result in a larger memory
footprint, which may be a problem on a machine with less RAM. It also
used to leak memory like a sieve, but most of those problems seem to
be resolved.
However, even with all the improvements to openwin, the libs, headers,
and imake it includes are broken. I will often install x.org or XFree
X11 on a Solaris system to make compiling X11 programs less of a
battle. Even when I use these libraries, I still run the Solaris X
server for it's DPS support, hardware support, and speed. If you run
into problems compiling X11 programs using openwin, try installing
x.org or XFree X11 from ftp://ftp.x.org/ or http://www.xfree.org/,
repsectively.
By default, Solaris uses CDE, the Common Desktop Environment. It's
the result of millions of dollars of development by IBM, HP, and Sun.
It's also a bloated nightmare and riddled with bugs. You can do some
nice things with it, but nothing you can't do in another environment.
Most importantly, all of the nifty CDE functionality requires a slew
of RPC-based support services (tooltalk, cmsd, etc.) which are the
source of a neverending series of remote exploits. I would recommend
choosing a different window manager. I'm partial
twm If you're on an 8bpp or black and white system, this works
great. It's very configurable, though you just can't make it
look fancy. You either love it or hate it. TWM is included
with any correct X distribution.
windowmaker Nice NeXT-like interface. Very configurable. Looks
great on a 24bpp framebuffer. You'll have to do some
work to keep it from eating all your colors on an 8bpp.
http://www.windowmaker.org/
blackbox Very fast, minimal window manager.
http://blackbox.alug.org/
pwm Similar to twm, but allows windows of the same class to be
grouped together with tabs.
http://www.students.tut.fi/~tuomov/pwm/
sawfish Programmable, modern window manager. I've not been using
it for very long yet, but I think I'll like it quite a lot.
http://sawmill.sourceforge.net/
There are also plenty of others that give you everything from full
configurability through a lisp interpreter to the exact look of
Windows 95 or Macos. These are just my personal favorites. Don't
email me to complain that I left out your favorite. This is MY
document, and I'll pimp MY favorite software :^). You can find a list
of X window managers at http://www.plig.org/xwinman/.
If users will have shell access, go through and remove or disable all
of the buggy and insecure software we've replaced. Even if a program
poses no security risk, it can be frustrating to users if they run
/usr/bin/patch and it crashes on them because it leaks memory. Link
/usr/bin/patch to /usr/local/bin/patch and make everyone happy.
There are a lot of apps that are setuid root that don't need to be.
Some of them just aren't used in on a typical system and are yet
another place for people to find security holes. Others are things
like ufsdump that should only be run by root in the first place. Some
of them, don't even NEED to be run as root and still work just fine.
You should use find(1) to get a list of all setuid and setgid programs
on your machine and do some sanity checking. The following are things
that I changed on my system. Your users may need to use some of
these, in which case you have to will them setuid and just pay
attention to bugtraq. You might want to be more paranoid and remove
even more than I did. To get a list of setuid software, run the
following:
find / -perm -4000 -print
and for setgid:
find / -perm -2000 -print
You will also want to make sure that any interesting devices (such as
your tape drive) do not have stupid permissions. You really don't
need an intruder overwriting your backup tapes with a copy of
/dev/zero. Use find to look for anything odd in /dev.
There are also plenty of directories with stupid permissions. You'll
probably want to remove the \0002 bit on most of these. Once again,
use find to get a list that's accurate for your system. Below are
some of the ones I fixed on my 2.6 box. I'm particularly nervous
about the directories in /var, because I don't want a user filling up
the log space before launching an attack. One thing you really ought
to do is put /var/mail on a separate file system to avoid this
problem, since there is no way to not give users write access to
/var/mail. (Note that this actually _isn't_ a problem if you install
a maildir or similar MTA like qmail that can store the user's mail in
their home directory where it belongs).
To find a list of world-writable directories, use the following
command:
find / -type d -perm -2
These are the ones I removed the world-writable bit from:
/var/preserve (this will upset some software. link to /usr)
/var/spool/pkg
/var/spool/lp/fifos/public
/var/spool/uucppublic
You should enable the sticky bit on any temporary directories to avoid
possible exploits taking advantage of race conditions. This is done
on by default on most of these directories on Solaris 8.
If you did not create /var/tmp as a separate partition, you might want
to relocate it to somewhere on /tmp (you'll have to create it at boot)
and symlink it. This prevents users from filling /var/tmp before
launching an attack to prevent the attack from being logged.
You should move /var/mail somewhere else. There's nothing like having
your mail spool fill up and not being notified because your logs all
go on the same partition. /var/mail also allows users to mask an
attack just like /var/tmp.
If you want to allow others to do some management of the system, I'd
recommend installing sudo or osh to avoid giving out full root
priveleges. It is very hard to limit what people can do, however, so
be careful, and never give privileged access to anyone you don't trust
completely. You may also want to install some goodies like a fake su
program to catch anyone who's trying to cause trouble.
If you need to provide any potentially dangerous services like NFS or
telnet, you should install ipfilter and tcp wrappers and configure
them to only allow access from trusted machines.
If you're extra paranoid, you should enable some of Solaris'
reasonably extensive auditing features. The man pages (audit_control,
audit_startup, auditconfig, audit_user, bsmconv) are quite good, and
there is no real reason to discuss the process here.
Another tool I haven't mentioned in any detail yet is aset. I plan to
include some information on it in the near future.
At this point, your Solaris box should be fairly secure. Always be
sure to follow mailing lists like bugtraq to keep up with new
developments. passwd(1) was found to have yet another exploit
recently, so you have to stay on top of things.
FURTHER READING
---------------
http://docs.sun.com/
Solaris System Administrator's Guide
by Janice Winsor
ISBN: 0130277029
Solaris 8 Advanced System Administrator's Guide
by Janice Winsor
ISBN: 0130277037
Configuration and Capacity Planning for Solaris Servers
by Brian L. Wong
ISBN: 0133499529
CREDITS
-------
This document has grown and been improved thanks to contributions,
suggestions, nagging and criticism from the following people (in
more-or-less chronological order):
Kolb Norbert
Michael Wilkinson
Super-User (root@hkhosting.com) (really. that's where it came from.)
Michael Douglass
Stephen Diercouff
Mark Benedetto King
Bill Bradford
Dan Debertin
Galen Johnson
If you wish to be removed from this list or if you feel you have been
left out, please contact me.
WILD, ENTHUSIASTIC REVIEWS
--------------------------
In case you're wondering if anyone actually reads this thing, as I was for a
long time, I have received some praise along with all the suggestion email.
Keep it coming! :^)
"It a quite good article. Nearly every admin has one of those files, I
guess, but this is the first I saw published."
"Thanks so much for putting fixsolaris.txt on the Web. I have some
sys admin experience, but none with Solaris. This information
was most helpful."
"...it is valuable even to experienced admins."
"Fix Solaris 8 was a very good read. Why don't you turn it into a book ??"