Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Solaris Hardening Bulletin 2004

Itch scratching, and audit (Score:3, Interesting) by RedPhoenix (124662) on Tuesday September 14, @09:15PM (#10251879)

At the risk of the post sounding like a discussion at a head-lice convention, everyone has their own personal itch to scratch. Several posts thus far, have questioned the viability of establishing yet another secure-debian project, similar to other existing projects, and have indicated that there would be a better use of available resources if everyone would just get along and work together (or at least, form under a single project). Fair enough. However, there are a whole range of reasons why diversity and natural selection w.r.t many competing projects can provide benefits over and above a single large project - organisational inertia, effective and efficient communication, and development priority differences, for example. 'Organisational inertia' in particular, whereby the larger a organisation/project gets, the slower it can react to changing requirements, is a good reason why this effort-amalgamation can potentially be a bad thing. Each of these projects probably has a slightly different 'itch' to 'scratch'. There's no reason why, later on down the track, that the best elements of each of these projects cannot be merged into something cohesive. A good example is the current situation in Linux Auditing (as in C2/CAPP style auditing and event logging, not code verification) and host-based audit-related intrusion detection. Over time, we've had Snare (http://www.intersectalliance.com), SLES (http://www.suse.com), and Riks Audit Daemon (http://www.redhat.com). Each project had a slightly different focus, and each development team have come up with some great solutions to the problems of auditing / event logging. The developers of each of these projects are now communicating and collaborating, with a view to bringing a effective audit subsystem to Linux that incorporates the best ideas from each approach. BTW: How about auditing in this project? Here's a starting point: http://www.gweep.net/~malk/snare_debian.shtml Red. (Snare Developer)

[Jan 27, 2005] Sys Admin Magazine/Tools to Help Harden Solaris™ by Kristy Westphal

There are several checklists on the Internet to help you lock down an out-of-the-box installation of Solaris. But, if you have followed any of them, you know how time consuming they can be, especially for a large enterprise. The Solaris community, however, is in luck when it comes to system hardening because a few forward-thinking Sun engineers have built some tools that can help to automate this procedure. In this article, I will discuss two such tools, TITAN and JASS.

... ... ...

A Comparison between TITAN and JASS

The experiment of seeing the differences between JASS and TITAN was very surprising. The first surprise was that the out-of-the-box, vanilla Solaris 8 installation passed several tests that I didn’t expect it to. Tests such as NFS running on privileged TCP and UDP ports, some default file permissions being set correctly (e.g., root owning /sbin, /etc not world writable), root cannot log in directly except on the console, and several default users were found in the ftpusers file. However, the issues that needed to be addressed far outweighed the default checks that passed the TITAN audit.

After running the JASS tool on an already installed machine, I re-ran the TitanReport script to see what had been done and what had been left open. JASS left open a few things that TITAN did not, such as:

• not configuring kernel auditing, (questionable idea unless you have too much disk space or very strict security requrements - nnb ;-)
• not locking down X access,
• setting strong default password strength in /etc/default/passwd,
• setting login defaults, not disabling sendmail,
• not adding all system users to ftpusers (like audit and news),
• and not setting a banner for telnet.

To see how TITAN stacks up, I ran it with the following:

<install dir>/Titan -f

The -f parameter is for “fix”.

Once TITAN was done fixing the system, I ran the TitanReport function again. There were only a handful of issues that TITAN could not fix because some of them still needed to be addressed outside of the environment (e.g., setting up a remote loghost and installing smrsh (sendmail restricted shell)) at the discretion of the sys admin. Some of the checks that failed will have to be investigated further to determine whether they are just not applicable to the system or if they just need to be manually fixed.

For instance, the last run of TitanReport claimed that the system did not pass the first check of XDMCP. Upon further investigation, it appears that although the system failed check one, it passed check two and is sufficiently secured. (Note that XDMCP (X Display Manager Control Protocol Description) looks for remote connections allowable through Xaccess.)

[Jan 23, 2004] freshmeat.net Project details for Tiger security tool -- attempt to reanimate Tiger

TIGER is a set of Bourne shell scripts, C programs, and data files which are used to perform a security audit of Unix systems. The security audit results are useful both for system analysis (security auditing) and for real-time, host-based intrusion detection.

freshmeat.net Project details for Slackware Administrators Security Toolkit

SAStk (Slackware Administrators Security tool kit) aims to provide a set of tools and utilities to install and maintain a reasonable level of security for the Slackware GNU/Linux distribution. At the same time, it should ease administration with a new centralized initialization setup and background information on what the daemons do.

[Jan 12th 2004]  ThePacketMaster 1.2.0  by thepacketmaster

About: ThePacketMaster Linux Security Server is a CD-based security auditing tool that boots and runs penetration testing and forensic analysis tools. It is handy for security auditors. Some tools included are nessus, ethereal, The Coroner's Toolkit, chntpw, and minicom. It includes modules for any Linux 2.4.20 SCSI driver.

Changes: This release updates the kernel to 2.4.24 to address issues found in 2.4.23 and earlier. It adds new packages for forensic analysis and vulnerability testing. /usr is now in a cloop filesystem for a smaller ISO image. XFree86 is now included, as well as the Enlightenment window manager, the Mozilla Web browser, and Java.

Last modified: February 28, 2008