Draft

Procedure for Conversion
of Application and Administrative Accounts to Roles

Role Based Access Control (RBAC) allows to create special accounts (called roles) that cannot be accessed via external login (for example telnet or ssh). It also permits unprivileged users to execute out privileged commands much like sudo.

While RBAC is conceptually similar to sudo (actually pfexec command is an almost exact replica of sudo functionality) , but is more versatile and starting with Solaris 10 much more powerful.  But even in Solaris 8 and 9 it is an attractive solution for several security related problems including,  but not limited to:

• Increasing the security of application account by blocking the ability to login to them (that's what wee need now)
• Creating typical roles like "netadmin" that provide access to tools like snoop, ifconfig, etc without the necessity to become root. This feature is similar sudo in Solaris 8 and 9, but it is much better then sudo in Solaris 10, where you can assume not the whole root role, but just the relevant privileges. 

One of the simple, yet important usage of RBAC is to control "application" accounts like "oracle", "webuser", "apache" etc. The idea is to convert a given account to a role and that automatically blocks all external logins.  This idea is far from being new, but still it is surprising how many enterprises do not use it.

You also need explicitly add the right to assume this role to accounts the need to su to it.

This procedure explains how to convert an application account to role on Solaris 8 and 9.  This is a better way to do this Solaris 10.

Converting an Existing Application and Administrative Accounts to Role

Step 1: Check if you are root. You need to be a superuser. We will use root as an example of conversion as it exists on any machine and most sysadmins can test this procedure directly on their personal Sun workstations. We will assume that the user joe_adm will be the account that is able to su to root. Other users can be added in a similar way.

Step 2: Backup existing authorization databases. There are four files that make up RBAC configuration:

• /etc/user_attr - contains roles and users for those roles
• /etc/security/exec_attr - contains commands
• /etc/security/prof_attr - contains profiles (which are a way of grouping commands together)
• /etc/security/auth_attr - contains built-in Solaris authorizations

Actually only /etc/user_attr needs to be backed up as this is the only file that is changed in this procedure.

Step 2:  Edit the /etc/user_attr file.

Here is a relevant fragment from a typical user_attr file.

root::::type=normal;auths=solaris.*,solaris.grant;profiles=All
joe_adm::::type=normal

Note: if /etc/passwd file was copied from another server there might be some or all the users that are absent from this file. For consistency you might want to add them. Generally it's better to do this with a script that converts "human" accounts into records of the format, shown above.

1. Edit the line for the account that you want to convert to role (root in our case) replacing type=normal with type=role. The result should be:
   
   root::::type=role;auths=solaris.*,solaris.grant;profiles=All
    
2. Change shell on the root account to /usr/bin/pfksh . This is the shell that checks for the privileges assigned to the role (actually the same executable as /usr/bin/ksh, just a hard link to it).  
    
3. Verify that you cannot telnet/ssh to the account anymore (telnet check not make sense for root, as it is already blocked by other means). After you provided the id of the role and password,  you should get a message that login failed because this account is a role, if you did steps 1-2 correctly.
    
4. Add root to the roles that are assigned to all relevant users (none of the users that you are adding should be active on the server).  For example to add it to user joe_adm you need

   usermod -R root joe_adm
    

   1. Verify that addition was successful in the /etc/user_attr :

      joe_adm::::type=normal;roles=root
       

   2. Su to one of the account that you added to the role
      
      su joe_adm
       
   3. Run command roles to verify that the user can accept this role
      
      # roles
      root

Notes: Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected. This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books. The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link. Search Amazon by keywords:     Open directory Research Index

News

[Feb 11, 2005] How To Create Custom Roles Using Based Access Control (RBAC)

#41168 How to set up RBAC to allow non-root user to manage in.named on DNS server

The following are assumed:

• The role is: dnsrole
• The user is: dnsadmin
• The profile is: DNS Admin ( case sensitive )
• Home directory for dnsrole is: /export/home/dnsrole
• Home directory for dnsadmin is: /export/home/dnsadmin

Configuration Steps

1. Create the role and assign it a password:

	# roleadd -u 1001 -g 10 -d /export/home/dnsrole -m dnsrole

	# passwd dnsrole

NOTE: Check in /etc/passwd that the shell is /bin/pfsh. This ensures that nobody can log in as the role.

Example line in /etc/passwd:

	dnsrole:x:1001:10::/export/home/dnsrole:/bin/pfsh

2. Create the profile called "DNS Admin":

Edit /etc/security/prof_attr and insert the following line:

	DNS Admin:::BIND Domain Name System administrator: 

3. Add profile to the role using rolemod(1) or by editing /etc/user_attr:

	# rolemod -P "DNS Admin" dnsrole

   Verify that the changes have been made in /etc/user_attr with profiles(1) or grep(1):

	# profiles dnsrole

	DNS Admin

	Basic Solaris User

	All

	# grep dnsrole /etc/user_attr             

	dnsrole::::type=role;profiles=DNS Admin

1. Assign the role 'dnsrole' to the user 'dnsadmin':

1. If 'dnsadmin' already exists then use usermod(1M) to add the role (user must not be  logged in):

      # usermod -R dnsrole dnsadmin

2. Otherwise create new user using useradd(1M) and passwd(1):

      # useradd -u 1002 -g 10 -d /export/home/dnsadmin -m \

      -s /bin/ksh -R dnsrole dnsadmin 

      # passwd dnsadmin

3. Confirm user has been added to role with roles(1) or grep(1):

      # roles dnsadmi

      dnsrole

      # grep ^dnsadmin: /etc/user_attr

      dnsadmin::::type=normal;roles=dnsrole

5. Assign commands to the profile 'dns':

Add the following entries to /etc/security/exec_attr:

	DNS Admin:suser:cmd:BIND 8:BIND 8 DNS:/usr/sbin/in.named:uid=0

	DNS Admin:suser:cmd:ndc:BIND 8 control program:/usr/sbin/ndc:uid=0

   If using Solaris 10 you may need to add a rule for BIND 9:

	DNS Admin:suser:cmd:BIND 9:BIND 9 DNS:/usr/sfw/sbin/named:uid=0

BIND 9 does not use ndc, instead  rndc(1M) is used which does not require RBAC.

6. Create or Modify named configuration files.

To further limit the use of root in configuring and maintaining BIND make dnsadmin the owner of /etc/named.conf and the directory it specifies.

	# chown dnsadmin /etc/named.conf

	# grep -i directory /etc/named.conf

		directory "/var/named/";

	# chown dnsadmin /var/named

7. Test the configuration:

   Login as the user "dnsadmin" and start named:

	$ su dnsrole -c '/usr/sbin/in.named -u dnsadmin'

 To stop named use ndc (for BIND 9 use rndc):

	$ su dnsrole -c '/usr/sbin/ndc stop'

Summary:

In this example the user 'dnsadmin' has been set up to manage the DNS configuration files and assume the role 'dnsrole' to start the named process.

The role 'dnsrole' is only used to start named and to control it with ndc (for BIND 8).  

With this RBAC configuration the DNS process when started by user 'dnsrole' would acquire root privileges and thus have access to its configuration files.

The named options '-u dnsadmin' may be used to specify the user that the server should run as after it initializes.  Furthermore 'dnsadmin' is then permitted to send signals to named as described in the named manual page.

References:

ndc(1M), named(1M), rbac(5), profiles(1), rolemod(1M), roles(1),

rndc(1M), usermod(1M), useradd(1M)

The Jail Chroot Project's purpose is to streamline the task of creating the chroot jail environment. It does so with utilities that "automagically configure & build all the required files, directories and libraries". It also makes adding new jailed accounts very easy. In this article, we'll take a look at the Jail Chroot Project utilities and show you how to install and use them to secure remote access accounts in a chroot-ed environment on your GNU/Linux system.

The basic idea

The Jail Chroot Project is the brain-child Juan M Casillas. On his web site, Juan explains how his utility works:

"Jail is a login tool. It works as a wrapper to the user shell, so when a user logs into the machine, Jail is launched, and the chrooted environment is activated. Then, Jail executes the real user shell, so he gets his session in the server.

The 'chrooted environment' is a subtree of the full tree in the filesystem, and the top of this subtree is viewed by the chrooted user as the root '/' entry of the tree. So Jail is useful for isolating users from the main filesystem's directory tree. As you can see in the diagram, the light-gray shaded boxes are the chrooted environment:"

Any user configured to be chroot-ed using Jail (such as user3 in the diagram) will be changed to his home directory (light-grey shaded box labeled user3) when that user logs into the machine. The root directory will appear to that user as the tree under the "chroot" directory. That is, user3 will only can see the files under the directory called 'chroot', thus locking that account in the "chroot jail", safely away from vital system files.

Installation

The installation of Jail Chroot is pretty standard *NIX fare. First, download the latest tarball (currently verion 1.9) at:

http://www.gsyc.inf.uc3m.es/~assman/jail/download/download.html

Once downloaded, simply unpack it with the command:

tar -zxvf jail_1.9.tar.gz

This will create a "jail_1-9_stable" directory where you unpack the file. Change directories to the one just created and you'll find a "src" directory. This is where you'll compile the utilities. Be sure to check the Makefile for your platform (Linux is set as the default). Simply issue a "make" and then "make install" as root to compile and install the utilities. Once you've gotten this far, you're ready to create the chroot-ed environment.

Creating the Jail

Once you've installed the Jail Chroot package, you're can build the chroot-ed jail environement. You'll need to decide where to build this environment, so take into consideration your partition sizes. For the purposes of this article, we'll create the chroot jail in the /home/jail dirctory. To set it up, run the following command as root:

/usr/local/bin/mkjailenv /home/jail

After executing the command, you should see text ouput similar to the following:

		Making chrooted environment into /home/jail
		        Doing preinstall()
		        Doing special_devices()
		        Doing gen_template_password()
		        Doing postinstall()
		Done.

Once complete, you've got a basic chroot environment installed in /home/jail. Now you'll need to add software for basic use in the jail.

Installing Software

The Jail Chroot utility adjailsw lets the system administrator choose between two methods of installing software for users in the jail. When your run the command without any arguments, addjailsw will add a default set of applications into the jail environment. To do this, run the following command as root:

/usr/local/bin/addjailsw /home/jail

This will install a group of basic commands for availablitilty in the chroot environment. These commands include some of the basics like ln, ls, mv, grep, cp, tail, touch and more. If you don't want to install the default set, you can use addjailsw with the -P option to specify each software package you want installed one by one in the chroot jail. For example, let's say you want to install the text editor joe. As root, just run the command

/usr/local/bin/addjailsw /home/jail -P joe

This will install joe for the chroot environment.

Adding inmates

Once you've added the software for your chroot environment, all that's left is to create user accounts. Prior to creating a user to the jail, you'll need to add him to your system in the normal fashion with adduser. You can use the adduser variables to create the appropriate paths in your main /etc/passwd file, or simply add the user and edit the /etc/passwd file manually. Any user placed in the jail should have their home directory listed as the chroot jail (/home/jail in our earlier example) and should specify the shell as /usr/local/bin/jail. The entry in the /etc/passwd file for a chroot-ed user should look something like this:

username:x:101:101:Jail User:/home/jail:/usr/local/bin/jail

Once you've specified the user to be jailed in your main /etc/passwd file, you can must then add him in chroot-ed environment. The Jail Chroot utility for doing this is called addjailuser and it has a very simple syntax. You must specify 4 variables when adding a user with addjailuser in the format:

addjailuser chrootdir userdir usershell username

The "chrootdir" variable is the path to the jail you've created. In our example, that would be /home/jail. (As you can see, this makes creating users in multiple chroot-ed environments very easy.) The "userdir" variable specifies the directory in the jail that will be the home directory for the user. To keep users consistent, we recommend creating a home directory for chroot-ed users just as you would for normal users. The only difference is that normal accounts will exist in the absolute path /home, and chroot-ed users will exist in the absolute path /home/jail/home, but will see essentially the same paths as normal users. The "usershell" variable points to the shell path inside the jail, so /bin/bash will be the norm, unless you install other shells in the environment. The "username" variable should be self-explanatory. Using these variables, you could add the username "fred" to our example jail in /home/jail with the command

addjailuser /home/jail /home/fred /bin/bash fred

This will create the necessary entries in the chroot-ed passwd file as well as create the directories for the user (/home/jail/home/fred) as well.

Simplicity and Security

Creating chroot jail environments used to be one of those dreaded tasks for system administrators. It was time consuming. It was tedious. And if you did something wrong, it was back to square one. The Jail Chroot Project streamlines these tasks and provides very easy to use tools for getting the job done. If you want to secure your remote access accounts with a chroot-ed environment on GNU/Linux (or any *NIX system for that matter), you need to get a copy of Jail Chroot Project tarball and get cracking. You'll be glad you did.

Chroot Jail Project Home Page

Slashdot Chroot Jails Made Easy

SecurityFocus/Configuring IPsec-IKE on Solaris Ido Dubrawsky, securityFocus

• Part One

• Part Two

• Part Three

RATS  2.0 released

RATS, the Rough Auditing Tool for Security, is a security auditing utility for C, C++, Python, Perl and PHP code. RATS scans source code, finding potentially dangerous function calls. The goal of this project is not to definitively find bugs. The current goal is to provide a reasonable starting point for performing manual security audits. RATS is released under version 2 of the GNU Public License (GPL).

Sudo Aliases and Exclusions

In his previous article, OnLamp's Michael Lucas looked at the basic sudo(8) setup. The hardest part of using sudo is configuring its permissions file, sudoers. As you can imagine, once you have several different machines with multiple administrators all with different levels of privilege, sudoers quickly gets very complicated. Aliases can simplify sudo maintenance and greatly clean up your sudo configuration.

Linux Journal On-Line

Stealthful Logging

Now it's time to combine the previous two techniques in a third one: stealth logging. Normally, a central log server runs syslog or syslog-ng. And indeed, it's possible to capture log packets via a non-IP-addressed interface with Snort and pass them to syslog or syslog-ng. However, it's a lot simpler to let Snort write the packets to a log file itself. The method I'm about to describe uses Snort, tail and awk instead of a traditional logger (on the central logserver, that is; on hosts that send logs you'll still need to configure syslog or syslog-ng as described below).

Suppose you have a LAN segment with several servers whose log messages you'd like sent to a single log server. Suppose further that you're far less concerned with the confidentiality of these log messages than with their integrity. You don't care if anybody eavesdrops the messages, but you don't want the messages tampered with once they've been received by the central log server. Your log server, therefore, is connected to the LAN via a non-IP-addressed interface and will sniff log packets sent to a bogus IP address on the LAN.

Configuring Your Hosts to Send Logs to the Stealth Logger

On each server from which you wish to send logs, you'll need to do two things. The first step is to configure each sender's system logger to send its messages to the bogus IP. By ``bogus'', I only mean that no host actually has that IP address; it must be valid for the LAN in question. Suppose our example LAN's network address is 192.168.1.0/24 and our bogus logger-host address is 192.168.1.111. Servers on the LAN that use standard syslog will each need a line like this in /etc/syslog.conf:

*.info @192.168.1.111
 

On servers that use syslog-ng, you'll need several lines in /etc/syslog-ng/syslog-ng.conf, like these:

destination d_loghost { udp(ip(192.168.1.111)
port(514)); };
filter f_info { level(info); };
log { filter(f_info); destination(d_loghost); };

In either case you may wish to specify different criteria from simply saying ``all messages whose severity is ‘info' or higher'', as shown in the above two examples.

Besides the appropriate lines in its logger's configuration file, each log sender will also need a static ARP entry for the bogus IP address. If your LAN consists of a hub or a series of ``cascaded'' hubs, this ARP address also can be bogus. If your LAN is switched, you'll instead need to specify the real MAC address (hardware address) of the log server. The command to add a static ARP entry on our example log-sending servers is:

arp -s 192.168.1.111 00:04:C2:56:54:58

where 192.168.1.111 is our bogus log-host IP, and 00:04:C2:56:54:58 is either a bogus MAC address or the real MAC address of our stealth logger's non-IP-addressed interface.

Now each server on our protected LAN is configured to send its logs to 192.168.1.111, and in the case of a switched LAN, they'll be sent to the stealth logger's switch port. Now all we need to do is configure the stealth logger itself

"Sree" <sreep@qnetstaff.com> writes:

>Dear Friends,
>how to provide su access to oracle user and disable direct logging throught
>ssh or telnet. only for user oracle.On Sun systems.

On Solaris systems with RBAC (s8+, I think) you can make the oracle
user into a "role"; that disables direct login access to the account
and also allows you to specify which users can su to it.


see user_attr(4) and rbac(5).

Casper

I've been looking at PAM, and it's a handful, IMHO.

Here's what I'm after; the question is, is there something
I can cannibalize to do this?

When a user logs in, I want to prompt them for the group
they intend to use.  I can do all the logic of checking
to see they're in the group and so forth, what I can't figure
out is how to go about giving the prompt and getting the
response.

Do I want to add to the stack in pam.conf?  That is, do I
want to simply add a line in a configuration file and
(I assume) supply the module to process that line?
That seems like the thing I'd most like to do.  I want
to be able to run this on Solaris if necessary.  If I
can write a module to process a line in pam.conf, then
it's trivial to add in the module and edit pam.conf, and
viola, I've got my extra requirement on any and all
machines I want.

I tried looking in several modules which I thought
would do something similar, but i just don't see
where the prompt is being sent, or the reply gotten.
Can you tell me where to look in an existing module
so I can see how it's done?

Or maybe I have the wrong idea altogether about PAM?

j.
-- 
Jay Scott		512-835-3553		gl@arlut.utexas.edu
Head of Sun Support, Sr. Operating Systems Specialist
Applied Research Labs, Computer Science Div.                   S224
University of Texas at Austin

Post a follow-up to this message

In article <al5m5j$c63@csdsun1.arlut.utexas.edu>,
Jay G. Scott <gl@arlut.utexas.edu> wrote:

[snip]

>
>When a user logs in, I want to prompt them for the group
>they intend to use.  I can do all the logic of checking
>to see they're in the group and so forth, what I can't figure
>out is how to go about giving the prompt and getting the
>response.

[snip]

a tip from Bruce Hudson (thx) got me started.


what i found out was that, while you can call setgid() from
lots of places, the only one which i found would remember
that setgid() had been called was in the pam_sm_setcred()
routine.  however, i couldn't get pam_setcred() to do the
prompting like i thought it should.  pam_sm_authenticate()
would prompt, but setgid() wouldn't be remembered.

i also didn't know that the way to get values passed from
one routine to another was via pam_set_data(),
pam_get_data().  now it's easy:  authenticate prompts
and calls pam_set_data(), setcred calls pam_get_data()
and calls setgid().

that, plus some relatively easy mods to pam.conf, and
i'm almost in business.

i notice that CDE's window for getting the group (my
addition, that is) contains the username, as though
that was the default group.  seems like that ought
to be a matter of zeroing the response msg before
calling the prompt, but to me, it looks like it is
zeroed.  perhaps i can simply supply new structs or
something.....

j.

-- 
Jay Scott		512-835-3553		gl@arlut.utexas.edu
Head of Sun Support, Sr. Operating Systems Specialist
Applied Research Labs, Computer Science Div.                   S224
University of Texas at Austin

http://travcom.tripod.com/ Free tools; two of note

• ps unhide - from tqbf@sockpuppet.com - shows process IDs in use, even if ps is trojaned
• viz.pl - show if someone has run zap or zap2 (log file erasers) on your system.

RC22534 "Thirty Years Later: Lessons from the Multics Security Evaluation." This is a fresh look, after 30 years, by the guys who did the seminal security analysis on Multics.

GeodSoft How-To Hardening Systems, Users, Groups and Security  --  George Shaffer page. He understand this littly understood area of Unix security better than most.

PatchPro Select here to download Patch Manager Base 1.0.

This application allows you to analyze your system, download required patches and install them. It also resolves patch dependencies when you install individual patches. Patch Manager Base 1.0 uses PatchPro to analyze, download and install patches. It has the same security features as PatchPro for Solaris 9.

Alexander Geschonneck's security page  This is a purely link page that contains some interesting links.

Solaris 9 Operating Environment Data Sheet -- Security in the Solaris 9 Operating Environment. It took Sun only ten years to integrate TCP-wrappers into the system ;-) Still if they managed to postponed this till 2002 it's unclear why not xinetd :-) Among other things: 

Solaris Secure Shell -- Now integrated into the Solaris 9 Operating Environment, Solaris Secure Shell enables secure and easy-to-use network administration. Based on the established OpenSSH...

System Minimization -- The new system packaging architecture of the Solaris 9 Operating Environment enables organizations to custom build a Solaris 9 system based on a higher granularity of available install packages. In short, fewer unnecessary packages installed on a system means fewer opportunities for system attack.

For example, Telnet is a standalone package as opposed to being a part of the core package. This allows for a system configuration where only service-specific features and systems applications are installed, and mitigates the risk of introducing a potential security hole.

TCP Wrappers -- TCP Wrappers capitalizes on the client-server relationship necessary for most TCP/IP applications by inserting itself into the middle of the relationship. Using its access control feature to authenticate hosts, it acts as the server until -- using its access control feature -- it authenticates the client/host.

The well-known TCP Wrapper application is fully integrated into the Solaris 9 Operating Environment. It provides an extremely effective method for monitoring and filtering incoming network requests for network services such as systat, finger, FTP, Telnet, rlogin, rsh, and more.

Sun and Tripwire : Working together to bring customers the best ...  -- actually Sun is an investor in Tripwire (I think Sun inverted around $5 millions)

What is the nature of the relationship between Sun and Tripwire?

The relationship between Sun and Tripwire is one of mutual technological interest. Sun is the leading producer of reliable, high-end server and computing environments and Tripwire is the leading provider of infrastructure integrity products from which those servers may be trusted.
... ... ...

What is the primary benefit of installing and using Tripwire software on a Sun Solaris server?

The primary benefit to a user of Tripwire software is the peace of mind it gives, knowing that data is in a
trusted state. Some key applications of Tripwire software are:

Integrity assessment
Intrusion detection
Damage assessment and recovery
Configuration management (aka Change Control Management)
Policy compliance and system lockdown
Forensics and sealing evidence

Can I manage multiple installations of Tripwire for Servers software from my Sun Solaris Server?

Yes. Tripwire Manager is a platform-independent management console from which thousands of Tripwire
for Servers installations may be easily controlled.

Can Tripwire software manage the integrity of my heterogeneous server network?

Absolutely. Through the use of Tripwire Manager software, you can manage thousands of Tripwire for
Servers installations from one Solaris server.

How can I get an evaluation copy of Tripwire for Servers software?

It's easy! Just go to http://sun.tripwire.com to obtain your free evaluation of Tripwire for Servers and
Tripwire Manager software.

Noel Davis examines security vulnerabilities in several common web server log file analysis tools. "In this column, we look at problems in analog, LogWatch, Java Web Start, libsafe, phpBB2, Posadis, Web+, libnewt, OpenLinux's Name Service Cache Daemon, SiteNews, phprojekt, and IRIX's FTP Server."

Slashdot Sun Reconsidering Solaris 9 for x86

One reason to keep it alive: SUNSCREEN (Score:2, Interesting) by Tora on Saturday April 20, @12:32AM (#3377847) (User #65882 Info)

One of the best little known firewalls to be found, and it is FREE on Solaris. This thing kicks the snot out of PIX and many other firewalls in a standalone configuration (it isn't too great for a large deployment of firewalls because it has no distributed management capability, ohwell). It has a real firewall front-end and frankly is one of the worst cases of mis-marketted technology next to the Alpha CPU. If you have Solaris 8, go download a copy of sunscreen and try it out, it rocks. So if you wanted a GOOD firewall, cheap; dont think linux, BSD or any other variant. Until recently you could get x86 solaris with Sunscreen.

[Mar 12, 2002] Security with Obscurity is Great. By Brian Hatch

For decades, inexperienced programmers have tried jury-rigging security onto software by implementing simplistic tricks that rely on obscurity rather than tried-and-true security measures. The assumption is that an attacker won't know to try something, and thus would not be able to get access to the software.

For example, lets say we have some fictitious Web-enabled device with an administrative interface living at http://example.com/XXXXXXX/, where XXXXXXX is the device's serial number. The manufacturer figures that only the administrator would be able to look on the back of the device and read the serial number, and thus this should be 'secure
enough'.

Problem
An attacker could easily discover that the admin interface is based on the serial number. Perhaps she has one of these units herself, or she finds newsgroup message from someone asking a question about the device. Regardless, the attacker need only whip up a quick 3 line shell script to try all possible URLs until they stumble on the correct one, and then there's nothing stopping them from taking over.

Had the manufacturer implemented some sort of password authentication, then the URL could have been something standard, say '/admin/'. Knowing the URL would do the cracker no good as she'd still need to know the password.

Security Through Obscurity

This kind of 'security' is called 'Security through Obscurity' and it is anything but. Ask any security guru and they'll constantly remind you that relying on Security through Obscurity is a vulnerability waiting to happen. To develop a solid security foundation, you must determine exactly what bits need to be secret and make sure that they are both secret and something that can be changed. In general, we're talking about passwords, keys, certificates, etc?.

So if you hang out on security lists enough, you'll often see folks trying to use obscurity as their sole security implementation. Sitting back and watching veterans sharply suggest that the newbies may be better off programming for someone who does not think security is required, such as a big corporation in Redmond, is fun.

Because of this instant negative reaction to Security through Obscurity, many folks don't ever use it. But this isn't necessarily the way to go. "Thou shalt not rely on security through obscurity" may as well be written, but there's no reason that you can't add security by adding obscurity. Just don't rely on it as your only defense.

In many cases, obscurity and misdirection can be helpful. Undoubtedly, crackers out on the 'Net have scanned large network blocks compiling a list of software installed on those machines. Should a new vulnerability be found in a particular version of software, then they have a list of hosts waiting to be attacked as soon as an exploit can be developed. For example, if you have Apache installed in the default manner, then it will show you a good bit about the configuration and modules installed:

$ curl -i http://www.example.com 2>/dev/null | grep Server
Server: Apache/1.3.9 (Unix) Debian/GNU PHP/4.0.3pl1

An attacker who has developed an exploit for the recent PHP bug need only consult her list of machines with PHP installed to begin hitting a number of likely targets. If you had told Apache to be minimalist in its server description by including the following directive in httpd.conf:

       ServerTokens min

Then the output would have been:

       $ curl -i http://www.example.com 2>/dev/null | grep Server
        Server: Apache/1.3.9

A lot less information is available here. Many network daemons can be configured to be less verbose, including most mailers and ftp servers. Unless there's a good reason to keep a version number or other identification around, have fun. Personalize your daemons. Why say:

   220 example.com ESMTP Sendmail 8.12.3.Beta0/8.9.3; 12 Mar 2002
   22:20:34

Thus giving out both your server and configuration versions, when it could instead read:

220 example.com ESMTP   All Your Base

Are Belong To Us

Be creative. And happy obscuring.

[Feb 09, 2002] xinetd package (with IPv6)

Xinetd is a secure replacement for inetd, the Internet services daemon. Xinetd provides access control for all services based on the address of the remote host and/or on time of access and can prevent denial-of-access attacks. Xinetd provides extensive logging, has no limit on the number of server arguments and you can bind specific services to specific IP addresses on your host machine. Each service has its own specific configuration file for Xinetd; the files are located in the /etc/xinetd.d directory. See http://synack.net/xinetd/

See also lf175, System Administration xinetd

[Jan 30, 2002] SecuriTeam.com ™ (Hardening the BIND DNS Server) -- Solaris oriented.

[Jan 28, 2002] Slightly Skeptical JASS Notes v.01 -- part of this page was made a separate file due to the volume and importance of the tool.

[Jan 28, 2002] Slightly Skeptical Notes on Titan v.02 -- part of this page was made a separate article due to the volume and importance of the tool.

[Jan 25, 2002] Generic Host Hardening for Any Computer  -- Every computer connected to the Internet is vulnerable to attack. Find out how to increase your computer's security through such measures as identifying a host's function; installing software patches, upgrades, and fixes; and setting up intrusion detection software. Read the article

[Jan 25, 2002] Architecting Secure Network Topologies  -- Your application may not be as safe as you think it is. Learn how to secure your network from the bottom up by getting the details on such topics as VLANs, VPNs, and the DMZ.

[Jan 25, 2002] A new version of The Solaris Fingerprint Database  (1.2) Download: sfpc-1.2.tar.Z and sidekick.sh.Z

For the use of

The Solaris[tm] Fingerprint Database - A Security Tool for the Solaris Operating Environment Files
sfpc-1.2.tar.Z - The Solaris[tm] Fingerprint Database Companion (sfpC) is a tool designed to automate the process of querying the Solaris Fingerprint Database (sfpDB).
sidekick.sh.Z - SideKick is a tool developed to automate the collection of MD5 files signatures.

[Jan 25, 2002] Solaris Security Toolkit is 0.3.4. Supports Solaris 2.5.1-2.8 on both Intel and Solaris. This version is better than prev. and much closer to quality to Titan. Hardened configurations are supported by Sun and that means some advantages over Titan for for enterprise customers. Among enhancements:

• added sunfire_15k_domain-[*].drivers from BluePrint article titled "Securing the Sun[tm] Fire 15K Domains" published January 2002
• forced locale to "C" as the code is not fully internationalized
• added set-root-group.fin script to set the root user's primary group to the value defined by JASS_ROOT_GROUP. This will help prevent that user sharing a common group identifier with non-privileged users.
• added JASS_ISA_CAPABILITY as a variable to indicate the ability of a system to operate in either 32 or 64-bit mode.
• modified make-jass-pkg to automatically determine JASS version from driver.init and to support "quiet" operation.
• added new hardening Sun Fire[tm] 15K System Controllers scripts based on BluePrints OnLine article 'Securing the Sun Fire 15K System Controller'
• included new nddconfig script which is Sun Cluster 2.x aware
• cleaned up default /etc/nsswitch.conf usage and modification

See Jass section for more details about this package

Solaris hole opening way for hackers - Tech News - CNET.com

• CERT Advisory CA-2001-31 Buffer Overflow in CDE Subprocess Control Service
• CERT Advisory CA-2002-01 Exploitation of Vulnerability in CDE Subprocess Control Service

Hardening OpenBSD Internet Servers

A Howto on hardening an OpenBSD Internet server but includes some sections that apply to any UNIX system. Information includes an introduction to hardening concepts, installing a minimum OpenBSD system, hardening OpenBSD, creating and using a recovery CD, user and password management, and users and security groups.

SRI International has released Emerald, an intrusion detection system for Solaris servers. A six month evaluation is available for download. It's unclear is much better/different from Snort.

Hidden sniffer howto

@(#) Hidden sniffer howto 06 MAR 2000 Rob Thomas robt@cymru.com HOWTO create a hidden sniffer with Solaris While experimenting with some code, I came up with this trick for creating an unseen Solaris sniffer. It is possible, when using snoop(1M), to sniff packets through an unplumb'd interface. The obvious benefit is that the interface can not be detected. Thus, the sniffer remains impervious to detection and attack. I was not able to use snoop(1M) on an unplumb'd interface until the interface had been configured. I suspect that this action loads the necessary module and configures the STREAM. Unfortunately, I have only been able to use snoop(1M) with an unplumb'd interface. The snort(8) tool does not seem to work. I was able to get tcpdump to work with this trick. Here are the steps to run the "unseen" sniffer:

Tuning-solaris-checkpoint.txt

@(#)Tuning Solaris for FireWall-1 v1.0 14 AUG 2000 Rob Thomas robt@cymru.com Tuning Solaris 7 for FireWall-1 4.0, by Rob Thomas Tuning Solaris for FireWall-1 by Rob Thomas Sun and Check Point have an intertwined history. Long resold as Solstice FireWall-1, it has become one of the most ubiquitous firewall packages in use today. While FireWall-1 on Solaris makes for a strong bastion, Solaris is not inherently tuned to provide filtering and routing services. This article will address some of the steps necessary to create an efficient and robust firewall.

Solaris x86 firewall using IP Filter is an article on building a firewall/gateway using Solaris and IP Filter on an Intel machine.

Internet Week Security Group Unveils Solaris Security Standards July 2, 2001

[Sept 4, 2001] Ask the Experts - searchSolaris.com The Solaris Specific Search Engine - a site that mainly advertises Sun papers, which is right and Sun scripts which is probably wrong :-)

Certainly Solaris systems ship with a number of services open and a particular set of default permissions. Each site has very different security requirements and different means of hardening their systems. There is also NO shortage of companies, organizations, consulting services and people who all claim to know best how to secure your system.

That being said, the best resource for securing and hardening your Solaris system is the set of Sun BluePrints articles that describe Solaris security. The link to these follows at the end. These articles cover a variety of topics including minimizing the number of packages on a system, disabling unused services, changing kernel and networking parameters, Trusted Solaris, setting default file permissions. Most importantly, beyond understanding WHAT to change, you must understand WHY to change it and even WHEN you should not change it. A FREE toolkit, known as the Solaris(tm) Security Toolkit, is provided on our Web site to allow you to implement the changes you deem appropriate for your site.

A note about the Solaris Security Toolkit. It is a flexible tool designed to run at initial install as a part of the Jumpstart network boot process, or at any time as a stand alone application. There are over 70 scripts included to harden your Solaris system, all of which can be grouped into profiles. For example, we include a profile for a minimized Web server machine. This profile runs the appropriate scripts to remove excess packages, increase file permission security and network security. The nice part about this tool is that they are proven at over 900 customer sites and is specifically designed to avoid violating the supportability of a server.

Specifically, look at http://www.sun.com/blueprints/ and browse the "Sun BluePrints OnLine" by subject for "Security". ...

[Aug 16, 2001] Solaris Central: Solaris Security Chat  Solaris Developer Connection Chat Sessions

Mark your calendar for August 16 at 1:00 EDT. That's when Martin Hack, Product Manager for Solaris Core Security will conduct an online chat about Security and Trusted Solaris. Along with his product management role, Martin oversees the Trusted Solaris Operating Environment. He has almost 10 years of experience in the computer and network security fields, and he's a key contributor for Sun's overall security strategy. Hack also determines future directions for security features in the standard Solaris Operating Environment, and he currently presents to international audiences on Sun's security products and strategies.

SourceForge Intergrit Project Filelist see also integrit file verification system and Sys Admin MagazinePaper  -- another Sorceforge v.01. tool ?  C-based, similar to Tripwire. Does not use Solaris Fingerprint MD5 database. Looks like doomed...

Ed L. Cashin

Integrit is a free software tool that helps sys admins stay in touch with and trust the files on their systems.

***** Sys Admin Magazine August 2001 Volume 10 Number 8 Locking the Front Door of Password Security by Victor Burns.

Burns describes a PAM created to check the strength of user-supplied passwords when user changes his/her password. Very good and simple approach to improving password security.

Securing SNMP on Solaris - by Reg Quinton 

The default SNMP configuration, while perhaps reasonably secure, can be made substantially more secure with a little effort. If you require SNMP services (e.g., to monitor a server in case of failover), you should configure it better.

Solaris Fingerprint Database Companion sfpC-1.2.tar.Z (05/01)

The Solaris Fingerprint Database Companion (sfpC) is a tool designed to automate the process of querying the Solaris Fingerprint Database (sfpDB). sfpC is used to process MD5 file signatures and present the collected database output information in human readable form. The tool eliminates the need for the manual task of cut and pasting MD5 output onto an HTML form. In addition, the tool performs the necessary checks to enable files of arbitrary size to be processed using multiple queries if necessary.

Download sidekick.sh.Z (05/01)

SideKick is a tool developed to automate the collection of MD5 file signatures. SideKick can be used to collect signatures for files known to be replaced by "rootkits", files with Set-UID or Set-GID permissions in addition to several other collection methods. SideKick can optionally be used with sfpC to automated the collection and processing of MD5 file signatures. SideKick can also be used in a standalone capacity for distributed signature collection.

Sun BluePrints OnLine - Articles June 2001 Jass v. 0.3 is Sun product similar to Titan, but oriented on JumpStart environment. Still pretty raw (this is really version .03). You can use the tool freely in your own private or corporate environment, but cannot distribute or publish derivative works. I read jass_internals-v03.pdf and it looks like this set of script does not provide any new ideas about how to write such tools.

"The Solaris Security Toolkit is a tool designed to assist in creation and deployment of secured Solaris Operating Environment systems. The Toolkit is comprised of a set of scripts and directories implementing the recommendations made in the Sun BluePrints OnLine program. These scripts can be executed on Solaris systems through the JumpStart technology or directly from the command line. The Toolkit includes scripts to harden, patch, and minimize Solaris Operating Environment systems. Sun does not support the Toolkit."

http://www.sun.com/blueprints
http://www.sun.com/blueprints/tools/
http://www.sun.com/blueprints/0601/jass_release_notes-v03.pdf
http://www.sun.com/blueprints/0601/jass_internals-v03.pdf
http://www.sun.com/blueprints/0601/jass_quick_start-v03.pdf
http://www.sun.com/blueprints/0601/jass_conf_install-v03.pdf

Summary of changes since version 0.2 (November 2000):

• Undo capability: This option, -u instructs the program that a previous run of the Toolkit is to be removed. Because the jass-execute program is used to access the undo feature, this feature is only available in standalone mode and not in JumpStart mode
   
• Updated framework: The Toolkit variable, JASS_CONFIG_DIR, has been renamed to JASS_HOME_DIR to provide a clearer meaning as to its use. The JASS_HOME_DIR is defined as the directory location in which the Toolkit is installed. The SCRIPTS* and FILES* variables now use the JASS_ prefix (i.e., JASS_SCRIPTS and JASS_FILES) for consistency. SUNWjass is now a reserved name for the Toolkit software package format distribution. The Toolkit is now available in this format, as well as in the original compressed tar format. The same source is distributed in both distributions. Administrators can also now make their own packages using the supplied make-pkg script.
  A new configuration file, finish.init, has been added to handle all finish script configuration variables. These variables still can be overridden by the user in the user.init file. This file was heavily commented to explain each variable, its impact, and its use in finish scripts.
   
• Changes to profiles
• New driver scripts
• Changes to driver scripts
• New + changed finish scripts
• New file templates: sendmail, c2 auditing
• Miscellaneous changes

Solaris Network Hardening  -- no-nonsense set of  hardening scripts by Reg Quinton, Information Systems and Technology . Looks like a Titan derivative with improved template. The author correctly stresses the importance of understanding of what you are doing when using Titan or YASSP. And that's an argument that strongly supports structuring the tool as a set of many simple scripts that you can enable/disable with fine granularity, so that sysadmin can create policy suitable for his needs. I saw many systems the were made unusable by naive application of some borrowed hardening policy. That is an interesting form of "hacker revenge" :-)

There is a security principle that says you should Configure computers to provide only selected network services (CERT® Coordination Centre). The basic idea is this: every network service you offer is an opportunity for the bad guys (alternatively a risk to your system). That's not to say that you shouldn't offer any services -- a mail server that doesn't offer mail services isn't very useful. Instead, the principle says you should have a good understanding of network services and you should not offer any service unless there are very good reasons for doing so. This paper is a discussion of the network hardening measures we've developed in the Solaris Network Hardening Kit -- an application of the principle.

A traditional Unix tar kit containing all scripts to harden each issue discussed, sample polices and a driver to implement policies is available here.

Some security packages address the problem by stripping all (or nearly all) network services and then instruct you to be careful about what you add to the system -- the YASSP: Yet Another Solaris Security Package (Jean Chouanard) is an instance of that. That's a great approach but requires that you "get your hands on" the system before anyone layers anything onto it and you understand what you're adding to the system when you add it back in. Two conditions that seldom apply at this site.

The approach here is different. We consider services offered by the Solaris operating system, try to explain what each does, note the risks involved with each and make recommendations about what one ought to do to mitigate the risk. For each issue discussed a hardening tool (a shell script) is provided to handle the issue. Typically, the issue is handled by removing a service that you don't need. Several policies are provided to harden typical systems and tools are given to enforce and monitor a policy.

[Jun 30, 2001] Solaris Network Hardening Kit  -- a new hardening package for Solaris.

There is a security principle that says you should Configure computers to provide only selected network services (CERT® Coordination Centre). The basic idea is this: every network service you offer is an opportunity for the bad guys (alternatively a risk to your system). That's not to say that you shouldn't offer any services -- a mail server that doesn't offer mail services isn't very useful. Instead, the principle says you should have a good understanding of network services and you should not offer any service unless there are very good reasons for doing so. This paper is a discussion of the network hardening measures we've developed in the Solaris Network Hardening Kit -- an application of the principle.

A traditional Unix tar kit containing all scripts to harden each issue discussed, sample polices and a driver to implement policies is available here.

Some security packages address the problem by stripping all (or nearly all) network services and then instruct you to be careful about what you add to the system -- the YASSP: Yet Another Solaris Security Package (Jean Chouanard) is an instance of that. That's a great approach but requires that you "get your hands on" the system before anyone layers anything onto it and you understand what you're adding to the system when you add it back in. Two conditions that seldom apply at this site.

The approach here is different. We consider services offered by the Solaris operating system, try to explain what each does, note the risks involved with each and make recommendations about what one ought to do to mitigate the risk. For each issue discussed a hardening tool (a shell script) is provided to handle the issue. Typically, the issue is handled by removing a service that you don't need. Several policies are provided to harden typical systems and tools are given to enforce and monitor a policy.

[Feb 1, 2001] The version  3.8 of Titan is available.

[Nov 1, 2000] Version 3.7 of Titan includes old version of fix-modes. God forbid using old version of fix-modes on Solaris 8. Update before running to the April 2000 version or you will  really have a chance to test your understanding of the Solaris ;-)

[Sept 26, 2000] SecurityPortal - Killing Daemons! By Jay Beale (jay@bastille-linux.org) for SecurityPortal

- If you install most Linux distributions, including Red Hat 6.x in the "Server" configuration, you'll find a number of optional system "daemons" running. Given the normal path of discovery of security vulnerabilities , one or more of these (totally optional) programs might have a bug that attackers can exploit to get root access. The problem is this: most system administrators don't know what all those programs on their systems do ! This article attempts to clear up the confusion, by describing the purpose of each of the running daemons on a Red Hat 6.1/6.x "Server" box and often giving suggestions for deactivation. While this article is a "must-read" for every Red Hat/Mandrake system administrator, executives should find this article useful as well, to get a general understanding and to help set a security policy.

Man_Solaris_2.5/pwck -- pwck, grpck - password/group file checkers

pwck scans the password file and notes any inconsistencies. The checks include validation of the number of fields, login name, user ID, group ID, and whether the login directory and the program-to-use-as-shell exist. The default password file is /etc/passwd.

grpck verifies all entries in the group file. This verification includes a check of the number of fields, group name, group ID, whether any login names belong to more than NGROUPS_MAX groups and that all login names appear in the password file. The default group file is /etc/group.

getpwent.3c group.4 passwd.4

Solaris Security Primer

Here is a simple approach which merely checks the files integrity against what was originally installed. If something has changed, i.e. someone has replaced a system binary with something malicious, it will find it. Of course if you don't scan everything, you won't really know.

This script will compare what is on a CD-ROM to what is on a hard drive. This assumes that you can fit everything important to you on a CD. I think this is fairly reasonable if you only take system/software binaries and not data. The minimal Solaris install is 200-300 MB depending on version, which will fit fairly easily on a CD. Having a good trusted backup is paramount. Without it you can only guess as to what has been changed.

#!/bin/sh

cd /cdrom
find . -type f | grep -v TRANS.TBL | \
        grep -v /proc | \
         while read F
do
        VAR1=`md5sum $F | awk '{print $1}'`
        VAR2=`md5sum ${F#.} | awk '{print $1}'`
        if [ "$VAR1" != "$VAR2" ]
        then
                echo $F CHANGED
                echo $VAR1 $VAR2
        fi
done

When setting up a system, include a run of the following script. It is paramount that this be done before connecting to the Internet. That way it is a "trusted" OS at the time you run this. If you had your system on the Internet for two years and then do it, you may have already been attacked, and just don't know it.

*** Comparison of Solaris Hardening Scripts -- not that impressive

Installing a virus filter for Sendmail Sunhelp.org article discusses how to use the AMaVIS;  the article goes into detail on what one must do to get this software working in the Solaris environment

Scanning Your Network (with Nmap) Dru Lavigne

TCP Slow Start Tuning For Solaris 2.6

FOCUS on Sun Solaris BSM Auditing

Defining Strategies to Protect Against TCP SYN Denial of Service Attacks -- Cisco paper

TCP-IP PSD-FAQ Solaris tips; useful document

Compass Security Network Computing AG  - several useful documents

• Hardening Solaris V0.86 -- Titan based
• Hardening WebSphere + IBMHTTPD V1.1
• Installation ssh2 for Solaris V2.0

sysadmin.oreilly.com -- dsniff and SSH Reports of My Demise are Greatly Exaggerated --Seifried false claims discussion

This is a misleading exaggeration. It becomes clear shortly that Seifried is talking about MITM. The existence of MITM is not a flaw in either protocol; in fact, both protocols include mechanisms to counter MITM. What is true is that, in most implementations, users may choose to override those mechanisms for the sake of convenience, forgoing MITM protection. One might take issue with this decision, but it is an implementation issue, not a protocol design flaw.

SunScreen[tm] 3.1 Lite Solaris 8 Users Get an Extra Layer of Security

Recommendations

I would recommend that all Solaris 8 users seriously consider installing the SunScreen 3.1 Lite firewall on their systems, be they workstations, print servers, or Internet Web servers.

I invite you to write to me directly at Mark.Thacker@Sun.com with questions concerning SunScreen 3.1 Lite or other security topics.

I encourage you to always follow best practices for securing Solaris workstations and servers. Please visit the links below, especially the Sun BluePrints OnLine site, which features recommended security practices.

Other Resources

• Sun Security Products -- Discussions of all of our security products
• SunScreen 3.1 Lite Download -- Available for SPARC and Intel Solaris
• Big Admin -- Sun's community portal for system administrators with sections on security
• Security white papers -- Papers and analysis of security topics
• BluePrints -- Sun's recommended practices on security, databases, etc.
• Documentation -- Most of Sun's product documentation in searchable HTML format
• SunSolve -- Patches to SunScreen, Solaris, and others
• Sun Security Consulting & Training -- Sun Education and Professional Services

*** [Oct 14, 2000]  Hardening Solaris: Creating a Diamond in the Rough Pt. I by Hal Flynn Recommends making an inventory using netstat and nmap. Nothing special... 

**+ SecurityPortal - Solaris 8 - Good and Bad (Great OS, Terrible Defaults) -- Covers Solaris on Intel; weak and superficial.

Configuring TCP-IP

In case the install program doesn’'t let you configure the network properly, you can do it by hand afterwards.

• /etc/nodename - put the nodename in there (sunbox)
• /etc/hostname.dnet0 - put the IP/hostname for that interface there (sunbox)
• /etc/defaultrouter - put the default gateway IP or name (gateway)
• /etc/inet/hosts - first set it writeable by root (chmod u+w /etc/inet/hosts), and then add the hostnames for your local machine and the gateway at a minimum
• /etc/inet/netmasks - put the local network(s) and netmasks in there

Configuring DNS

• copy /etc/nsswitch.dns over /etc/nsswitch.conf
• /etc/defaultdomain - put the default domainname (example.org)
• edit /etc/resolv.conf so you have:

nameserver 1.2.3.4
domain example.org
search example.org

Running BIND v8 chrooted on Solaris 5-6-7

FOCUS on Sun Solaris Default Processes and init.d Pt. I

This article has been written to provide insight into a stock installation of Solaris 8, and the services started by default. Solaris 8 by default runs many services. This example was provided using Solaris 8, which is the latest version available, and a Sparcstation 20. Most of this document will apply to releases of Solaris prior to 8, and to both the Sparc and Intel architectures. For documentation purposes, a full OEM install was done. Many topics discussed will be familiar to seasoned administrators. However, this document will benefit all parties involved in the administration and security aspects of Solaris.

FOCUS on Sun Solaris and inetd.conf Part 1

This collection of material has been written to further clarify one of the more mystical configuration files on today's Solaris Operating System. For this example, we make use of the latest distribution of Solaris (at this time, 7). The topics covered are quite familiar to most seasoned administrators, although this publication has been written with administrators from beginning to advanced skill levels in mind.

***+ SAGE ;login - Auditing - The Ugly Duckling of Computers  -- old but useful paper [ Jul 10, 2000]

Setting Up Auditing: The Specifics for Solaris 2.X

The auditing package that comes with Solaris is part of the BSM (Basic Security Module) package. The audit daemon auditd is the process that performs the auditing on Solaris systems. It is started by default if the /etc/security/audit_startup file exists. The actions that can be audited are defined in the /etc/security/audit_event file. This file can be customized, but it is very in-depth and beyond the scope of this article (the answerbook has a very good description of the whole process and files involved).

Audit flags indicate which classes of events to audit. Systemwide defaults are listed in /etc/security/audit_control. This file is very important and is the basis for the rest of the discussion. This file is similar to the "User Manager->Polices->Audit" setup in NT; it controls will be audited on the system and what will not. Set up improperly, and you will either have too much information or too little. A man on audit_classes(4) will give you a large amount of information. In standing with my initial recommendations, here is an audit_control file to start with:

dir:/etc/security/audit
flags:lo,ad,-fm,-fc,-nt
naflags:lo,ad
minfree:10

Let's see what this means. The first line defines the directory for the audit files to be placed. This location must have adequate space; if it fills up it will lock you out.[1] You can have more than one dirflag in the file, and they will be used in the order specified. The second line is for events attributable to a user, and tells us the following: (see the audit_event file for list of actions that fall into a class):

lo ­ all login and logout events
ad ­ all administrative actions
-fm ­ all failed change of object attributes (chmod, flock, etc.)
-fc ­ all failed creation of objects
-nt ­ all failed Network events (This may be noisy)

The third line is for events that are not attributable to a specific user. The fourth line tells us the minimum free in the dir files before we get a warning message from the audit system. The audit -s command will cause the auditd to reread this file after editing.

The other file of interest is the /etc/security/audit_user. This file allows more specific auditing of individual users. If specified, the flags in this file are combined with the global flags in audit_control to provide a more granular auditing ability.

Keeping Solaris Audit Files Manageable

To keep audit file manageable, a cron job can be set up to periodically rotate the audit files. The audit -n command will checkpoint the logs. This process closes the current audit log and opens another. Then you can process the just closed audit file. Figure 1 is a rudimentary script that will process the just closed audit log. Figure 2 is a script to store and rotate audit logs created during the auditreduce portion, a simple modification of the newsyslog script.

Audit maintenance on Solaris has a steep learning curve, but it flattens out pretty quickly. The best documentation is in the answerbook. It is specific and very descriptive. I recommend that anyone not strongly familiar with Solaris auditing read it before you implement the system.

Conclusion

Now that my primary job is helping those unfortunate individuals or sites with security incidents, I see the errors in not taking the time in 1991 to "finish the job." In an incident, if you don't have good logs (i.e., auditing), you'd better have good luck. The chances of figuring out what happened without good auditing are few and far between. If you take one thing from this article, make it this: Take the time, learn your systems, and set up auditing that is adequateand appropriate for your systems.

In the next issue, I will discuss central management of UNIX and NT audit files.

Sun BluePrints OnLine - Articles January 2000 SolarisTM Operating Environment Security -- PDF document. By Alex Noordergraaf and Keith Watson [Jan 2000].

The Solaris Operating Environment is a flexible, general purpose operating system. Due to its general nature, changes must be made to secure the system against unauthorized access and modification. This article discusses the Solaris Operating Environment subsystems and the security issues surrounding those subsystems. Recommendations are made on the manner in which those subsystems should be secured.

As with any security decisions, a balance must exist between system manageability and security. Some changes in this article will not be applicable to all environments. The removal of some of the Solaris Operating Environment services mentioned in this article may negatively impact the ability to effectively maintain a system. You must know your system and security requirements before starting.

This article splits the discussion of the Solaris Operating Environment system security into two parts. The first section deals with file system and local security. The second half of this article deals with the security of network services.

The information in this article applies to the Solaris 2.5.1, 2.6, and 7 Operating Environment. Some system changes described in this article have been integrated into Solaris 8 Operating Environment. Where appropriate, these new changes are mentioned. Older versions of the Solaris Operating Environment may be configured in similar ways. Some investigation is necessary before making the changes suggested in this article to these older versions.

***** SolarisTM Operating Environment Minimization for Security- A Simple, Reproducible and Secure Application Installation Methodology

***** Solaris^TM Operating Environment Network Settings for Security
  -by Keith Watson and Alex Noordergraaf
  Discuss the many low-level network options available within Solaris and their impact on security.

Etc

• Network Magazine Back Issues January 1999 Managing Unix Security
• Solaris - tuning your TCP-IP stack [Jan 15, 2000]
• Medstat Operations Manual -- online book  for Solaris [Jan 12, 2000]
  • Contents 

• Solaris Security Issues  -- pretty recent slides with comments (from University of Pennsylvania Friday, October 22, 1999 UNIX Security Workshop)[Jan 12, 2000]

• POLYCENTER Security Compliance Manager for Solaris 2, Version 2.5 -- something old.[Jan 10, 2000]

• Sun Security Information[Jan 10, 2000]

• Basic Solaris Security Setup from SDSU_Security_Index[Jan 10, 2000]

• Univ of Oregon Solaris Security  -- good; contains unique info on some steps (adding ASET, etc.)[Jan 10, 2000]

• docs.sun.com System Administration Guide  Executable Stacks and Security[Dec 20, 1999]

• Sun Security Bulletin Archive

• Hardening the Linux Kernel (series 2.0.x) ---[ Phrack Magazine Volume 8, Issue 52 January 26, 1998, article 06 of 20

Last modified: March 15, 2008