Solaris Hardening Bulletin 2003

env_audit -- a program that ferrets out everything it can about the environment. It looks for process IDs, UID, GID, signal masks, umask, priority, leaked file descriptors, and environmental variables. It comes with test configurations for anacron, apache, atd, crond, GDB, inittab, logrotate, PHP, pppd, procmail, rsh, rxvt, sendmail, SSH, stunnel, sudo, xinetd, and xterm.

I have released a white paper outlining the use of env_audit in conducting a survey of process environments of well known public programs. It includes: apache 2.x, php, stunnel, pppd, gdb, and xinetd among others. The paper exposes problems with these programs. Of these, the problems in apache 2.x are the worst and in need of attention. If you use any of the above mentioned programs, you should read the report !

environments.pdf (~300k, Nov 20, 2002)

Freshmeat/pam_passwdqc 0.7.5  by Solar Designer - Sunday, November 2nd 2003 16:07 PDT

About: pam_passwdqc is a simple password strength checking module for PAM-aware password changing programs, such as passwd(1). In addition to checking regular passwords, it offers support for passphrases and can provide randomly generated passwords. All features are optional and can be (re-)configured without rebuilding.

Changes: The module will now assume invocation by root only if both the UID is 0 and the PAM service name is "passwd". This should fix changing expired passwords on Solaris and HP-UX and make "enforce=users" safe. The proper English explanations of requirements for strong passwords will now be generated for a wider variety of possible settings.

[Nov 2, 2003] PAM modules

pam_passwdqc
Linux (Linux-PAM), FreeBSD-current (OpenPAM), Solaris, HP-UX 11

pam_passwdqc is a simple password strength checking module for PAM-aware password changing programs, such as passwd(1). In addition to checking regular passwords, it offers support for passphrases and can provide randomly generated passwords. All features are optional and can be (re-)configured without rebuilding.

More information on pam_passwdqc and download links are available on its dedicated page.

pam_userpass
Linux (Linux-PAM)

PAM has traditionally assumed that services doing authentication have the ability to interact with the user. Unfortunately, this isn't true for services that implement non-interactive and/or fixed protocols, such as FTP and POP3. This is typically worked around by making the flawed assumption that PAM_PROMPT_ECHO_ON requests the username and PAM_PROMPT_ECHO_OFF requests the password.

With pam_userpass, this assumption is no longer required. pam_userpass uses PAM binary prompts (only available in Linux-PAM) to ask the application for the username and password specifically.

pam_userpass doesn't perform any actual authentication. An actual authentication module should be stacked after pam_userpass and told to use the authentication token (password) provided by pam_userpass.

Download:

• pam_userpass 0.9.1 and its signature

pam_mktemp
Linux (Linux-PAM), others?

pam_mktemp is a PAM module which may be used with a PAM-aware login service to provide per-user private directories under /tmp as a part of PAM session or account management. When an interactive (shell) session is started, a directory is created and the environment variables TMPDIR and TMP are set to the name of the directory.

Download:

• pam_mktemp 0.2.5 and its signature

pam_tcb
Linux (Linux-PAM) + glibc with crypt_blowfish

pam_tcb is a part of the Openwall GNU/*/Linux (Owl) tcb suite implementing the alternative password shadowing scheme. It also makes use of the password hashing framework introduced with crypt_blowfish. It should be used in place of modules such as pam_unix and pam_pwdb.

More information on the tcb suite and download links are available on its dedicated page.

These files are also available via FTP.

Follow this link for information on verifying the signatures.

All of these modules are fully integrated into Owl and distributions by ALT Linux team. Additionally, pam_passwdqc has recently been integrated into FreeBSD-current, is used on ASPLinux, and is a part of SuSE Linux.

 

Support further work on this software with donations.

[Nov 2, 2003]  Freshmeat/pam_passwdqc 0.7.5  by Solar Designer - Sunday, November 2nd 2003 16:07 PDT

About: pam_passwdqc is a simple password strength checking module for PAM-aware password changing programs, such as passwd(1). In addition to checking regular passwords, it offers support for passphrases and can provide randomly generated passwords. All features are optional and can be (re-)configured without rebuilding.

Changes: The module will now assume invocation by root only if both the UID is 0 and the PAM service name is "passwd". This should fix changing expired passwords on Solaris and HP-UX and make "enforce=users" safe. The proper English explanations of requirements for strong passwords will now be generated for a wider variety of possible settings.

[Sept 24, 2003]Solaris Boasts Improved Security, Peformance And Virtualization Storage Pipeline

Sun Microsystems is planning some upgrades to its Solaris operating system designed to increase speed and flexibility.

Mark Tolliver, executive vice president of marketing and strategy and chief strategy officer at Sun, used his keynote presentation at the SunNetwork Conference, held this week in San Francisco, to tell a crowd of corporate users and channel partners about some of changes they should expected.

Tolliver touted Solaris as the most stable operating system on the market, especially with its binary compatibility across platforms and between version numbers. For instance, when Sun upgraded from version 8 to version 9 of Solaris, the company had to migrate 233 applications to the new operating system, he said. "Two-hundred thirty-two applications had no problem," he said. "We fixed Solaris, not the application, so now we're 233 for 233."

For the next version of Solaris, dubbed Solaris Next by Tolliver, Sun will incorporate most of the security features of Trusted Solaris, the company's security-hardened version of the operating system, said Tolliver.

Sun is also planning to add a new feature--Advanced Tracing--which Tolliver said will allow administrators to monitor the network across the entire network environment and across all processes.

Also coming in the near future is Network Performance, which gives Solaris wire-speed performance over TCP/IP networks, Tolliver said, adding that the feature should increase Solaris performance over such networks by a factor of 10.

In addition, Sun is planning to bring Trusted Containers to Solaris. Trusted Containers allow servers to be virtualized into larger servers, with each server set up in a secure "container" as a way to consolidate a data center's server environment, said Tolliver. Up to 4,000 such containers can be configured on a single server, he said.

Andy Tucker, distinguished engineer and architect for Trusted Containers, said the containers are completely isolated from each others, so each container cannot see applications outside of its own secure bounders. At the same time, the file system is virtualized so that each container, or "zone," can have its own virtual file system, he said.

Tolliver said to expect the Network Performance module to be available in October, with Trusted Containers to be available in the first quarter of 2004.

All of the upcoming Solaris features will also be available on Solaris x86 version as well, Tolliver said.

During Tolliver's keynote, he brought out Neil Knox, Sun's executive vice president of volume systems products, to discuss low-cost servers. Knox, in response to canned questions from Tolliver, hinted that Sun may introduce a four-way, x86-based server at the company's next quarterly SunNetwork Conference.

Knox also said to expect technology changes that will increase the performance of Sun Fire V440 servers in the "not too distant future."

Tolliver also introduced Daniel Jackson, president and COO of DeepNines Technologies, which is developing security products for the Solaris environment. In response to Tolliver's question of why DeepNines is developing for Solaris only, Jackson took a jab at Microsoft by answering, "We can't call ourselves a security company if we build on an insecure OS."

[Feb 18, 2003] Privacy International is holding a "stupid security" competition and is inviting folks to report pointless security measures they've witnessed over the last year.

PI Launches Competition to Find the World's Most Stupid Security Measure.
Privacy International has launched a competition to discover the world's most pointless, intrusive and self-serving security initiatives. The "Stupid Security" Award will highlight measures which are outrageously pointless and illusory, and which cause unnecessary distress and annoyance. Nominations are open to everyone. The winners will be announced in New York on April 3rd. Announcement and Guidelines.

http://www.sun.com/bigadmin/content/submitted/Solaris_build_document.pdf a 55 page Solaris hardening document by Gideon Rasmussen. 

The document details the configuration, hardening, monitoring and vulnerability assessment of the Solaris operating system. It can also be used as a configuration standard, providing a baseline to audit against.

New and updated Sun blueprints that might be worth reading

• Minimizing the Solaris[tm] Operating Environment for Security: Updated for Solaris 9 Operating Environment (November 2002)
  -by Alex Noordergraaf
  This article provides tips, instructions, and preferred practices for minimizing the Solaris Operating Environment (Solaris OE) to increase system security. It focuses on operating system (OS) installation practices for minimizing and automating Solaris OE installations. It provides a simple, reproducible, and secure application installation methodology.
  
   
• Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part II (October 2002)
  -by Michael Haines and Joep Vesseur
  This article is part two of a two-part series and details the PAM application programming interface (API) and the PAM service provider interface (SPI). Also included are procedures on how to effectively write PAM modules when using the Solaris[tm] 9 Operating Environment (Solaris 9 OE). By writing these PAM service modules, it is possible to extend the capability of the Solaris 9 OE authentication mechanisms in a number of different ways.
  
  Part one, Extending Authentication in the Solaris[tm] 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part I, was published in the September 2002 issue of Sun BluePrints[tm] Online.
   
• Extending Authentication in the Solaris[tm] 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part I (September 2002)
  -Michael Haines
  This article is the first of a two-part series that offers a technical overview of how the Solaris[tm] 9 Operating Environment implementation of Pluggable Authentication Modules (PAM) works. This article demonstrates straightforward methods for configuring PAM to accommodate site-specific security policy requirements and examines the PAM architecture and its components.

• How Hackers Do It: Tricks, Tools, and Techniques (May 2002)
  -by Alex Noordergraaf
  Learn how to build and maintain secure systems and implement preventive solutions against the common tricks, tools, and techniques used by hackers to gain unauthorized access to Solaris[tm] Operating Environment systems.

Env_audit Homepage

Env_audit is a program that ferrets out everything it can about the environment. It is ideal for looking for security problems due to misconfiguration or software bugs. Software developers that write any program that shells out to run a command should be audited with this software. It looks for all process IDs, signal masks, umask, process priority, leaked file descriptors, rlimits, and environmental variables.

It comes with test configurations for: anacron atd, apache, crond, php, sshd, stunnel, and xinetd. If you create additional tests and would like to publish them, let me know.

Download the latest copy: env_audit-1.04.tar.gz (Oct 21, 2002)

Here is an example output of anacron on a RedHat 8.0 system.

Chroot Jails Made Easy with the Jail Chroot Project

Published by LinuxOrbit.com, October 10, 2002 by John Gowin, Linux Orbit Editor-in-chief and Chris "Speedman" Heaven, President Beonix Technology There are always difficult jobs to do as a GNU/Linux system administrator. Sometimes the difficulty lies in finding out how to do a particular job, not neccessarily the job itself. This can be particularly true in the open source world where documentation can often take a back seat to implementation. But once in a while, you can stumble on a real gem that simplifies even the most difficult administration tasks. One such gem is the Jail Chroot Project. So what is a "chroot jail"? Essentially it is a security method for creating a safe user enviroment on systems that allow remote access accounts. The "jail" locks users into a virtual directory structure and grants access only to applications created for the jailed users by the administrator. It has long been a standard for hosting companies to create remote access accounts with this method, but the process was far from simple. Creating each account took many steps and needed thorough testing to assure system security. 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" <[email protected]> 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		[email protected]
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 <[email protected]>,
Jay G. Scott <[email protected]> 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		[email protected]
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 [email protected] - 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 [email protected] 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 [email protected] 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 ([email protected]) 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 [email protected] 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

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019