Here are the key security levels from the Orange Book standard: Table 1.2. Orange Book NIST Security Levels Level Description A Least protection - no protection from casual or coincidental violation of security. B Moderate protection - casual violation of security policy is prevented. C Substantial protection - threats from well-managed casual violation of security are nullified. B1 Moderate protection for individual users. B2 Moderate protection for connected systems. B3 Moderate protection for networked systems. A1 Least protection for individual users. The Orange Book, also known as the Trusted Computer System Evaluation Criteria (TCSEC

1. Unix Administration Guide
A Quick Reference Guide for Clustering, Security, Virtualization and
General Administration for Solaris and Linux Operating Systems;
Private Version.
Robert Bailey

2. Unix Administration Guide: A Quick Reference Guide for Clustering,
Security, Virtualization and General Administration for Solaris and
Linux Operating Systems; Private Version.
Robert Bailey
Version 1.4 - In Progress
Abstract: Obscure UNIX Procedures and Tasks
This document covers Solaris 10, RHEL 5.3, and some AIX when using advanced topics such as LDOM's, Live
Upgrades with SVM Mirror Splitting, FLAR Booting, Security Hardening, VCS Application Agent for Non-Global
Zones, and IO Fencing. Many procedures are my own, some from scattered internet sites, some from the Vendors
documentation.
You are welcome to use this document, however be advised that several sections are copied from vendor documentation
and various web sites, and therefore there is a high possibility for plagiarism. In general, this document is a collection
of notes collected from a number of sources and experiences, in most cases it is accurate, however you should note
that typo's should be expected along with some issues with command line and file output that extends beyond the
format of this document.
<legalnotice>
THE MATERIALS ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND
NON-INFRINGEMENT. FURTHERMORE YOU MAY NOT USE THIS DOCUMENT AS A MEANS OF PROFIT, OR FOR CORPORATE
USAGE, WITHOUT THE EXPLICIT CONCENT FROM THE AUTHOR.
</legalnotice>

3. Table of Contents
1. Security Overview .......................................................................................................... 1
Definitions and Concepts ............................................................................................. 1
2. Project Live Cycle .......................................................................................................... 7
General Project Overview ............................................................................................ 7
Pre Test Data Collection .............................................................................................. 8
Scripting Test Cases ................................................................................................... 9
3. RAID Overview ............................................................................................................ 12
Purpose and basics .................................................................................................... 12
Principles ................................................................................................................ 13
Nested levels ............................................................................................................ 13
Non-standard levels ................................................................................................... 14
4. Solaris Security ............................................................................................................. 15
BSM C2 Auditing ..................................................................................................... 15
BSM Secure Device Control ....................................................................................... 17
General Hardening .................................................................................................... 19
Destructive DTrace Examples ..................................................................................... 19
IPFilter Overview ..................................................................................................... 20
IPSec with Shared Keys ............................................................................................. 23
IPSec With 509 Certs ................................................................................................ 26
Apache2 SSL Configuration with Self-Signed Certs ........................................................ 29
RBAC and Root As a ROLE ...................................................................................... 31
Secure Non-Global Zone FTP Server ........................................................................... 32
Trusted Extensions .................................................................................................... 35
5. Solaris Virtualization ..................................................................................................... 39
Logical Domains ...................................................................................................... 39
Socket, Core and Thread Distribution ................................................................... 39
Install Domain Manager Software ........................................................................ 39
Configure Primary Domain ................................................................................. 40
Create DOM1 .................................................................................................. 40
Adding RAW Disks and ISO Images to DOM1 ...................................................... 40
Bind DOM1 and set up for booting ...................................................................... 40
Install OS Image and Clean up DOM1 ................................................................. 41
Create LDOM #2 .............................................................................................. 41
Backup or Template LDOM Configurations ........................................................... 41
Add one virtual disk to two LDOMs .................................................................... 41
Grouping VCC Console ..................................................................................... 43
LDOM Automation Script .................................................................................. 43
VCS and LDOM Failover, Features and Start and Stop ............................................ 45
VCS LDOM with ZPool Configuration ................................................................. 47
Manual LDOM and Zpool Migration .................................................................... 48
xVM (XEN) Usage on OpenSolaris 2009.06 .................................................................. 49
Quick Create for Solaris 10 HVM ....................................................................... 49
Solaris 10 Non-Global Zones ...................................................................................... 49
Comments on Zones and Live Upgrade ................................................................ 49
Comments on Zones and Veritas Control .............................................................. 51
Basic Non-Global Zone Creation SPARSE ............................................................ 52
Scripting Basic Non-Global Zone Creation SPARSE ............................................... 53
Using Dtrace to monitor non-global zones ............................................................. 54
Setup a Non-Global Zone for running Dtrace ......................................................... 55
Using Dtrace to trace an applincation in a non-global zones ...................................... 55
Using Dtrace to monitor non-global zones ............................................................. 55
iii

4. Unix Administration Guide
Non-Global Zone Commands .............................................................................. 56
Non-Global Zones and Stock VCS Zone Agent ...................................................... 59
Non-Global Zones and Custom VCS Application Agent ........................................... 60
6. Solaris WANBoot ......................................................................................................... 64
General Overview for Dynamic Wanboot POC .............................................................. 64
POC Goals .............................................................................................................. 64
POC Out of Scope .................................................................................................... 64
Current challanges with wanboot marked for resolution ................................................... 65
POC Wanboot Configuration Highlights ....................................................................... 65
Next Steps .............................................................................................................. 65
Configuration Steps .................................................................................................. 65
7. Solaris 10 Live Upgrade ................................................................................................. 69
Solaris 8 to Solaris 10 U6 Work A Round ..................................................................... 69
Review current root disk and mirror ............................................................................. 70
Create Alternate Boot Device - ZFS ............................................................................. 71
Create Alternate Boot Device - SVM ........................................................................... 71
Patch, Adding Packages, setting boot environment and Installation examples ........................ 72
8. Solaris and Linux General Information .............................................................................. 75
Patch Database Information ........................................................................................ 75
SSH Keys ................................................................................................................ 76
RHEL 5.2 NIS Client ................................................................................................ 76
Redhat Proc FS Tricks ............................................................................................... 76
Force a panic on RHEL ..................................................................................... 76
Adjust swap of processes ................................................................................... 76
iSCSI Notes - RHEL 53 Target SOL 10U6 Initiator ........................................................ 77
Setup Linux NIC Bonding .......................................................................................... 78
Linux TCP sysctl settings .......................................................................................... 79
Linux Dynamic SAN HBA Scan ................................................................................ 80
Solaris 10 - Mapping a process to a port ....................................................................... 81
Network and Services Tasks for Linux ......................................................................... 82
Hardening Linux ....................................................................................................... 83
9. Solaris 10 Notes ........................................................................................................... 88
Link Aggregation ...................................................................................................... 88
Link Aggregation ...................................................................................................... 89
IPMP Overview ........................................................................................................ 90
IPMP Probe Based Target System Configuration ............................................................ 91
Using Service Management Facility (SMF) in the Solaris 10 OS ........................................ 92
MPXIO ................................................................................................................... 98
USB Wireless Setup WUSB54GC .............................................................................. 100
VCS MultiNICB without probe address - link only ........................................................ 101
Network IO in/out per interface ................................................................................. 101
Register Solaris CLI ................................................................................................ 102
NFS Performance .................................................................................................... 102
iSCSI Software Target Initiator .................................................................................. 103
iSCSI Target using TPGT Restrictions ........................................................................ 105
iSCSI Software Initiator ........................................................................................... 106
SVM Root Disk Mirror ............................................................................................ 106
Replace Failed SVM Mirror Drive ............................................................................. 110
ZFS Root adding a Mirror ........................................................................................ 113
Create Flar Images .................................................................................................. 114
FLAR Boot Installation ............................................................................................ 114
ZFS Notes ............................................................................................................. 121
ZFS ACL's ............................................................................................................. 123
ZFS and ARC Cache ............................................................................................... 125
iv

5. Unix Administration Guide
10. VMWare ESX 3 ........................................................................................................ 128
Enable iSCSI Software Initiators ................................................................................ 128
General esxcfg commands ........................................................................................ 128
General vmware-cmd commands ................................................................................ 131
Common Tasks ....................................................................................................... 132
Shared Disks with out RAW Access ........................................................................... 133
Using vmclone.pl clone script ................................................................................... 134
Clone VMWare Virtual Guests .................................................................................. 137
Clone VMWare Disks .............................................................................................. 138
LUN Path Information ............................................................................................. 139
11. AIX Notes ................................................................................................................ 141
Etherchannel ........................................................................................................... 141
12. Oracle 10g with RAC ................................................................................................. 143
Oracle General SQL Quick Reference ......................................................................... 143
Oracle 10g RAC Solaris Quick Reference ................................................................... 143
Oracle 10g R2 RAC ASM Reference .......................................................................... 145
Oracle 10g R2 RAC CRS Reference ........................................................................... 146
Oracle RAC SQL .................................................................................................... 147
13. EMC Storage ............................................................................................................ 152
PowerPath Commands ............................................................................................. 152
PowerPath Command Examples ................................................................................. 152
Disable PowerPath .................................................................................................. 153
INQ Syminq Notes .................................................................................................. 154
Brocade Switches .................................................................................................... 155
14. Dtrace ...................................................................................................................... 158
Track time on each I/O ............................................................................................ 158
Track directories where writes are occurring ................................................................ 159
15. Disaster Recovery ...................................................................................................... 160
VVR 5.0 ................................................................................................................ 160
VVR Configuration ......................................................................................... 160
General VVR Tasks using 5.0MP3 ..................................................................... 163
VVR and GCO v5.x Made Easy ...................................................................... 166
VVR 4.X ............................................................................................................... 175
Here's now to resynchronize the old Primary once you bring it back up 4.x: .............. 175
Failing Over from a Primary 4.x ....................................................................... 176
Setting Up VVR 4.x - the hard way ................................................................... 178
Growing/Shrinking a Volume or SRL 4.x ........................................................... 179
Removing a VVR volume 4.x .......................................................................... 180
16. VxVM and Storage Troubleshooting ............................................................................. 181
How to disable and re-enable VERITAS Volume Manager at boot time when the boot disk
is encapsulated ........................................................................................................ 181
Replacing a failed drive ........................................................................................... 183
Storage Volume Growth and Relayout ........................................................................ 183
UDID_MISMATCH ................................................................................................ 185
VxVM Disk Group Recovery .................................................................................... 186
Resize VxFS Volume and Filesystem ......................................................................... 187
Incorrect DMP or Disk Identification .......................................................................... 187
Data Migration out of rootdg .................................................................................... 188
Recover vx Plex ..................................................................................................... 188
Shell code to get solaris disk size in GB ..................................................................... 188
Split Root Mirror vxvm ............................................................................................ 189
If VxVM Split Mirror needs post split recovery ............................................................ 190
17. Advanced VCS for IO Fencing and Various Commands .................................................... 192
General Information ................................................................................................. 192
v

6. Unix Administration Guide
SCSI3 PGR Registration vs Reservation ...................................................................... 193
SCSI3 PGR FAQ .................................................................................................... 194
IO Fencing / CFS Information ................................................................................... 195
ISCSI Solaris software Target and Initiator Veritas Cluster Configuration with Zones ........... 203
Heart Beat Testing .................................................................................................. 206
Software Testing Heart Beats - unsupported ......................................................... 206
Heart Beat Validation ...................................................................................... 206
Using Mirroring for Storage Migration ........................................................................ 207
18. OpenSolaris 2009.06 COMSTAR ................................................................................. 213
Installation ............................................................................................................. 213
Simple Setup An iSCSI LUN .................................................................................... 213
Walkthrough of Simple iSCSI LUN Example ............................................................... 214
Setup iSCSI with ACL's ........................................................................................... 214
19. Sun Cluster 3.2 .......................................................................................................... 217
Preperation ............................................................................................................. 217
Installation ............................................................................................................. 218
Basic Configuration ................................................................................................. 220
General Commands ................................................................................................. 224
Create a Failover Apache Resource Group ................................................................... 225
Create a Failover NGZ Resource Group ...................................................................... 227
Create a Parallel NGZ Configuration ......................................................................... 227
Oracle 10g RAC for Containers ................................................................................ 229
Zone and QFS Creation and Configuration .......................................................... 229
Sun Cluster RAC Framework ............................................................................ 233
20. Hardware Notes ......................................................................................................... 234
SunFire X2200 eLOM Management ........................................................................... 234
SP General Commands ..................................................................................... 234
Connection via Serial Port ................................................................................ 234
System console ............................................................................................... 234
To Set Up Serial Over LAN With the Solaris OS .................................................. 235
Configure ELOM/SP ....................................................................................... 235
5120 iLOM Management .......................................................................................... 236
vi

7. List of Tables
1.1. Identifying Threats ....................................................................................................... 1
1.2. Orange Book NIST Security Levels ................................................................................. 2
1.3. EAL Security Levels ..................................................................................................... 3
1.4. EAL Security Component Acronyms ............................................................................... 5
4.1. Common IPFilter Commands ........................................................................................ 22
5.1. Coolthreads Systems ................................................................................................... 39
5.2. Incomplete IO Domain Distribution ............................................................................... 39
5.3. VCS Command Line Access - Global vs. Non-Global Zones .............................................. 59
6.1. Wanboot Server Client Details ...................................................................................... 65
10.1. esxcfg-commands .................................................................................................... 128
12.1. ASM View Table .................................................................................................... 146
13.1. PowerPath CLI Commands ....................................................................................... 152
13.2. PowerPath powermt commands .................................................................................. 152
17.1. Summary of SCSI3-PGR Keys .................................................................................. 196
19.1. Sun Cluster Filesystem Requirements .......................................................................... 217
vii

8. Chapter 1. Security Overview
Definitions and Concepts
1. Vulnerability
Is a software, hardware, or procedural weakness that may provide an attacker the open door he is looking
for to enter a computer or network and have unauthorized access to resources within the environment.
Vulnerability characterizes the absence or weakness of a safeguard that could be exploited.
2. Threat
Is any potential danger to information or systems. The threat is that someone or something will identify
a specific vulnerability and use it against the company or individual. The entity that takes advantage
of a vulnerability is referred to as a threat agent. A threat agent could be an intruder accessing the
network through a port on the firewall, a process accessing data in a way that violates the security
policy, a tornado wiping out a facility, or an employee making an unintentional mistake that could
expose confidential information or destroy a file's integrity.
3. Risk
Is the likelihood of a threat agent taking advantage of a vulnerability and the corresponding business
impact. If a firewall has several ports opened there is a higher likelihood that an intruder will use one
to access the network in an unauthorized method. Risk ties the vulnerability, threat, and likelihood of
an exploitation to the resulting business impact.
4. Exposure
Is an instance of being exposed to losses from a threat agent. A vulnerability exposes an organization
to possible damages. If a company does not have it's wiring inspected it exposes , and dose not put
proactive fire prevention steps into place, it's self to a potentially devastating fire.
5. Countermeasures or Safeguards
Is risk mitigation. A countermeasure may be a software configuration, hardware device, or a procedure
that eliminates a vulnerability or reduces the likelihood a threat agent will be able to exploit a
vulnerability. Examples include strong password management, BIOS password, and security awareness
training.
6. Putting the concepts together
Table 1.1. Identifying Threats
Threat Agent Can Exploit This Resulting in This Threat
Vulnerability
Virus Lack of antivirus software / not Virus infection
up to date definitions
Hacker Powerful services running on a Unauthorized access to
server confidential information
Users Misconfigured parameter in the System malfunction
operating system
1

9. Security Overview
Threat Agent Can Exploit This Resulting in This Threat
Vulnerability
Fire Lack of fire extinguishers Facility and computer damage,
and possible loss of life
Employee Lack of training or standards Sharing mission-critical
enforcement; Lack of auditing information; Altering data
inputs and outputs from data
processing applications
Contractor Lax access control mechanisms Stealing trade secrets
Attacker Poorly written application; Lack Conducting buffer-overflow;
of stringent firewall settings Conducting a Denial-of-Service
attack
Intruder Lack of security guard Breaking windows and stealing
computers and devices
7. Orange Book Security Levels
<security, standard> A standard from the US Government National Computer Security Council (an arm
of the U.S. National Security Agency), "Trusted Computer System Evaluation Criteria, DOD standard
5200.28-STD, December 1985" which defines criteria for trusted computer products. There are four
levels, A, B, C, and D. Each level adds more features and requirements.
Levels B and A provide mandatory control. Access is based on standard Department of Defense
clearances.
Orange Book n. The U.S. Government's (now obsolete) standards document "Trusted Computer
System Evaluation Criteria, DOD standard 5200.28-STD, December, 1985" which characterize secure
computing architectures and defines levels A1 (most secure) through D (least). Modern Unixes are
roughly C2.
Table 1.2. Orange Book NIST Security Levels
NIST Level Description
D is a non-secure system.
C1 Requires user log-on, but allows group ID.
C2 Requires individual log-on with password and an
audit mechanism. (Most Unix implementations
are roughly C1, and can be upgraded to about C2
without excessive pain).
B1 Requires DOD clearance levels.
B2 Guarantees the path between the user and the
security system and provides assurances that the
system can be tested and clearances cannot be
downgraded.
B3 Requires that the system is characterised by a
mathematical model that must be viable.
A1 Requires a system characterized by a
mathematical model that can be proven.
8. Evaluation Assurance Levels
2

10. Security Overview
The Evaluation Assurance Level (EAL1 through EAL7) of an IT product or system is a numerical grade
assigned following the completion of a Common Criteria security evaluation, an international standard
in effect since 1999. The increasing assurance levels reflect added assurance requirements that must
be met to achieve Common Criteria certification. The intent of the higher levels is to provide higher
confidence that the system's principal security features are reliably implemented. The EAL level does
not measure the security of the system itself, it simply states at what level the system was tested to see if
it meets all the requirements of its Protection Profile. The National Information Assurance Partnership
(NIAP) is a U.S. Government initiative by the National Institute of Standards and Technology (NIST)
and the National Security Agency (NSA).
To achieve a particular EAL, the computer system must meet specific assurance requirements. Most
of these requirements involve design documentation, design analysis, functional testing, or penetration
testing. The higher EALs involve more detailed documentation, analysis, and testing than the lower
ones. Achieving a higher EAL certification generally costs more money and takes more time than
achieving a lower one. The EAL number assigned to a certified system indicates that the system
completed all requirements for that level.
Although every product and system must fulfill the same assurance requirements to achieve a particular
level, they do not have to fulfill the same functional requirements. The functional features for each
certified product are established in the Security Target document tailored for that product's evaluation.
Therefore, a product with a higher EAL is not necessarily "more secure" in a particular application than
one with a lower EAL, since they may have very different lists of functional features in their Security
Targets. A product's fitness for a particular security application depends on how well the features listed
in the product's Security Target fulfill the application's security requirements. If the Security Targets
for two products both contain the necessary security features, then the higher EAL should indicate the
more trustworthy product for that application.
Table 1.3. EAL Security Levels
Assurance Levels Description
EAL1: Functionally Tested EAL1 is applicable where some confidence in
correct operation is required, but the threats to
security are not viewed as serious. It will be of
value where independent assurance is required
to support the contention that due care has
been exercised with respect to the protection of
personal or similar information. EAL1 provides
an evaluation of the TOE (Target of Evaluation)
as made available to the customer, including
independent testing against a specification, and
an examination of the guidance documentation
provided. It is intended that an EAL1 evaluation
could be successfully conducted without
assistance from the developer of the TOE, and
for minimal cost. An evaluation at this level
should provide evidence that the TOE functions
in a manner consistent with its documentation,
and that it provides useful protection against
identified threats.
EAL2: Structurally Tested EAL2 requires the cooperation of the developer
in terms of the delivery of design information and
test results, but should not demand more effort
3

11. Security Overview
Assurance Levels Description
on the part of the developer than is consistent
with good commercial practice. As such it should
not require a substantially increased investment
of cost or time. EAL2 is therefore applicable
in those circumstances where developers
or users require a low to moderate level of
independently assured security in the absence of
ready availability of the complete development
record. Such a situation may arise when securing
legacy systems.
EAL3: Methodically Tested and Checked EAL3 permits a conscientious developer
to gain maximum assurance from positive
security engineering at the design stage
without substantial alteration of existing sound
development practices. EAL3 is applicable in
those circumstances where developers or users
require a moderate level of independently assured
security, and require a thorough investigation of
the TOE and its development without substantial
re-engineering.
EAL4: Methodically Designed, Tested, and EAL4 permits a developer to gain maximum
Reviewed assurance from positive security engineering
based on good commercial development
practices which, though rigorous, do not require
substantial specialist knowledge, skills, and
other resources. EAL4 is the highest level at
which it is likely to be economically feasible
to retrofit to an existing product line. EAL4
is therefore applicable in those circumstances
where developers or users require a moderate to
high level of independently assured security in
conventional commodity TOEs and are prepared
to incur additional security-specific engineering
costs. Commercial operating systems that provide
conventional, user-based security features are
typically evaluated at EAL4. Examples of such
operating systems are AIX[1], HP-UX[1],
FreeBSD, Novell NetWare, Solaris[1], SUSE
Linux Enterprise Server 9[1][2], SUSE Linux
Enterprise Server 10[3], Red Hat Enterprise
Linux 5[4], Windows 2000 Service Pack 3,
Windows 2003[1][5], Windows XP[1][5],
Windows 2008[1], and Windows Vista[1].
Operating systems that provide multilevel
security are evaluated at a minimum of EAL4.
Examples include Trusted Solaris, Solaris 10
Release 11/06 Trusted Extensions,[6] an early
version of the XTS-400, and VMware ESX
version 3.0.2[7].
EAL5: Semiformally Designed and Tested EAL5 permits a developer to gain maximum
assurance from security engineering based upon
4

12. Security Overview
Assurance Levels Description
rigorous commercial development practices
supported by moderate application of specialist
security engineering techniques. Such a TOE will
probably be designed and developed with the
intent of achieving EAL5 assurance. It is likely
that the additional costs attributable to the EAL5
requirements, relative to rigorous development
without the application of specialized techniques,
will not be large. EAL5 is therefore applicable in
those circumstances where developers or users
require a high level of independently assured
security in a planned development and require a
rigorous development approach without incurring
unreasonable costs attributable to specialist
security engineering techniques. Numerous
smart card devices have been evaluated at EAL5,
as have multilevel secure devices such as the
Tenix Interactive Link. XTS-400 (STOP 6) is a
general-purpose operating system which has been
evaluated at EAL5 augmented. LPAR on IBM
System z is EAL5 Certified.[8]
EAL6: Semiformally Verified Design and Tested EAL6 permits developers to gain high assurance
from application of security engineering
techniques to a rigorous development
environment in order to produce a premium
TOE for protecting high value assets against
significant risks. EAL6 is therefore applicable to
the development of security TOEs for application
in high risk situations where the value of the
protected assets justifies the additional costs.
An example of an EAL6 certified system is
the Green Hills Software INTEGRITY-178B
operating system, the only operating system to
achieve EAL6 thus far.[9]
EAL7: Formally Verified Design and Tested EAL7 is applicable to the development of
security TOEs for application in extremely high
risk situations and/or where the high value of
the assets justifies the higher costs. Practical
application of EAL7 is currently limited to TOEs
with tightly focused security functionality that is
amenable to extensive formal analysis. The Tenix
Interactive Link Data Diode Device has been
evaluated at EAL7 augmented, the only product
to do so.
Table 1.4. EAL Security Component Acronyms
Acronym Description
TCSEC Trusted Computer System Evaluation Criteria
LSPP Labelled Security Protection Profile
5

13. Security Overview
Acronym Description
CAPP Controlled Access Protection Profile
RBAC Role Based Access Control Protection Profile
9. Bell-Lapadula model
a. A security level is a (c, s) pair: - c = classification – E.g., unclassified, secret, top secret - s = category-
set – E.g., Nuclear, Crypto
b. (c1, s1) dominates (c2, s2) iff c1 ¸ c2 and s2 µ s1
c. Subjects and objects are assigned security levels - level(S), level(O) – security level of subject/object
- current-level(S) – subject may operate at lower level - f = (level, level, current-level)
10.DAC vs. MAC
• Most people familiar with discretionary access control (DAC); - Example: Unix user-group-other
permission bits - Might set a file private so only group friends can read it
• Discretionary means anyone with access can propagate information: - Mail sigint@enemy.gov <
private
• Mandatory access control - Security administrator can restrict propagation
6

14. Chapter 2. Project Live Cycle
General Project Overview
Projects typically are manifested through either a self initiated, top down or bottom up direction. In a Top
Down project, there is a pre-stated goal and problem identified - details on solution typically get resolved at
lower levels so long as the overal stated goal is met. Bottom Up is operations driven and generally as an end
result goal in mind. The solution may need additional approval, however the general project already has
management backing. Bottom Up can also come from general meetings with operational groups personnel
and therefore need review by their management.
Should the project be the result of a self initiated direction several additional steps are needed; including
getting management and operations buyin; identifying budget and time allocation; and budget approval -
including vendor negotiations where needed.
The most important parts of any project are getting management/group buyin, and defining components
such as scope, success, and timelines.
• Identify demand - documentation of the problem.
1. What problem needs to be resolved
2. Who does the problem impact?
3. What is the priority of the problem?
4. Are there existing solutions in place that need to be adapted, or is this a new problem?
• Collect statistics on current issue
1. Audit problem
2. Identify timelines for current actions
3. Identify groups involved
• Identify preliminary options to solve the problem
1. Brainstorming sessions
2. Are there known vendor solutions - if so, who are the major players?
3. If internal solution - possible test case examples (minimal time invested)
4. Pre-project POC - if internal solution
• Project initiation proposal
1. Outline Demand - what problem is to be solved
2. Identify key management players for buyin
3. Expected results from solution - will time be saved? will a major problem be avoided?
4. Overview of who will be involded - initial key technology players
7

15. Project Live Cycle
5. How long is the project expected to last?
6. What metrics will be needed and collected for the pre/post project analysis?
7. How is success defined?
• Kickoff meeting
1. Define scope - what options and solutions are needed, what are the priorities, what items are must
vs. nice to have. Also identify what is related but out of scope. If project is to be broken down into
phases, that should be identified and the second phase and greater needs to be "adapted for" but not
part of the success of the initial phase. It is good, when multiple groups are involded, to have each
report back with their weighted options list (RFE/RFC).
2. Define ownership - including contact information
3. Milestones and Goals; including dependencies and serialized processes
4. Setup timelines and re-occuring meetings
5. Make sure there are next steps and meeting notes posted.
• Handling RFE/RFC Metrics and Weighted Items
1. Should vendor solutions be needed create a weighted requirments list. Should a vendor not be needed
the same items should be identified for cross-team participation; or with the impacted group.
2. Define what vendors will be sent the weighted list
3. Develop the weighted list; usually 1-10 plus N/A. Information about a feature that is only included
in the next release may be presented seperatly however it should have no weight.
4. Define expected completion date of the RFC by the vendor
5. Corelate answers based on weight and identify the optimal product for evaluation. Should more than
one be close in score; there is a potential for a bake-off between products.
• Post Project Review and Presentation
1. Comparison of Pre/Post Project Metrics
2. Credits to all involved
3. Examples of Success - feedback from operations
Pre Test Data Collection
Define standard method of collecting data; this defines the audit trail of the pre-test server. Recommend
new build for testing whenever possible.
• Define and document baseline system
• BART Manifest to track changed files
• BSM Audit Enabled to track commands
• Manual Documentation of Tasks with timelines
8

16. Project Live Cycle
• Use logger to mark manual tasks and milestones
• If possible, run VXexplorer or SUNexplorer and save a copy remote
• Write a script to copy off key files - should be written based on test type
• Define rollback method - snapshot / LU Alternate Boot
Example BART Data Collection ; run copy against all necessary directories; in this example that would
include /etc and /zone; if milestones are involved then frequest collections of bart may be necessary to
track overall changes within different enviironment stages. Just name the manifest based on the stage.
# mkdir /bart-files
# bart create -R /etc > /bart-files/etc.control.manifest
Scripting Test Cases
Break down large tests into sub tests; such as Certifying VCS would amount to certifying each resource
creation, execution, and failover response then the results are grouped together by function then product;
if done well, then you only have to certify the new add-ons when expanding the test, example below:
• Define Agents used on all clusters and expected response
• Seperate tests unique to a specific cluster type - RAC, Oracle DB Failover, Apache, etc
• Break down tasks such as Storage Allocation and Control
• Adding VCS Disk Group
• Adding Filesystem Mounts
• Max projected number of Disk Groups and Filesystems
• Include any special details such as ownership changes; largefiles; qio; ufs
• Recommend scripting templates using XML into minor tasks - example shows using DITA to define
a task to create a vote volume for RAC
<task id = "vote_vol_reation"
xmlns:ditaarch = "http://dita.oasis-open.org/architecture/2005/">
<title>Create a CFS Vote Filesystem for CRS</title>
<shortdesc>Describes how to make a CFS volume for the vote
filesystem for SFRAC deployments</shortdesc>
<taskbody>
<prereq><p>The cvm_CVMVolDg_scrsdg resource needs to be online.
And all volume creation commands for CVM run on the CVM master:
&CVMMaster;</p></prereq>
<steps>
<step><cmd>Create Vote Volume on scrsdg disk group </cmd>
<stepxmp>
<screen>
ssh &CVMMaster;
vxassist -g scrsdg make vote 1G group=dba user=oracle mode=664
mkfs -V vxfs -o largefiles /dev/vx/rdsk/scrsdg/vote
9

17. Project Live Cycle
</screen>
</stepxmp>
</step>
<step><cmd>Create Directories on both $Node0; and $Node1;</cmd>
<stepxmp>
<screen>
# On &Node0; and &Node1;
mkdir -p /oracle/dbdata/vote
chown -R oracle:dba /oracle/dbdata
chmod 774 /oracle/dbdata
chmod 774 /oracle/dbdata/vote
</screen>
</stepxmp>
</step>
</steps>
</taskbody>
</task>
• This could be broken down even further with the right processing script
<task id= "T11001">
<title>Volume Creation</title>
<comments>Template Creates a Veritas Volume when
passed an ENTITY value for the following:
Disk Group: &DG
Volume Name: &VOL
Volume Size: &SIZE
User Owner: &USER
Volume Permission Mode: &MODE
</comments>
<command>/usr/sbin/vxassist -g &DG; make &VOL;
&SIZE; user=&USER; mode=&MODE;
</command>
<return>1</return>
</task>
• Tasks could be templated to execute as a sequence as a procedure- DITA Map is good for this, but
example is just off-the-cuff xml
<procedure id = "P001">
<title>Create Volume, Filesystem and add into VCS</title>
<task id = "T1001"/>
<task id = "T1002"/>
<task id = "T1003"/>
<return>1</return>
</procedure>
• Procedures could be grouped together as part of a certification
<certification id="C001">
<title>SFRAC 5.0 MP3 Certification</title>
<procedure id= "P001"/>
<procedure id= "P002"/>
<procedure id= "P003"/>
<return>1</return>
10

18. Project Live Cycle
</certification>
• Execution Code for tasks/procedures should be able to pass back a return code for each task; probably
best to return time to execute also. These numeric return codes and times would be best placed into a
database with a table simular in concept to cert ( id, procedure, task , results) and cross link to a cert_info
(id, description, owner, participants, BU, justification)
• If all is done well, then the certification tasks are re-usable for many certifications and only need to be
written once, the process is defined and can be reproduced, and every command executed is logged and
could be used to generate operational procedures.
11

19. Chapter 3. RAID Overview
Purpose and basics
Note
Information collected from wiki
Redundancy is a way that extra data is written across the array, which are organized so that the failure
of one (sometimes more) disks in the array will not result in loss of data. A failed disk may be replaced
by a new one, and the data on it reconstructed from the remaining data and the extra data. A redundant
array allows less data to be stored. For instance, a 2-disk RAID 1 array loses half of the total capacity that
would have otherwise been available using both disks independently, and a RAID 5 array with several
disks loses the capacity of one disk. Other RAID level arrays are arranged so that they are faster to write
to and read from than a single disk.
There are various combinations of these approaches giving different trade-offs of protection against
data loss, capacity, and speed. RAID levels 0, 1, and 5 are the most commonly found, and cover most
requirements.
• RAID 0 (striped disks) distributes data across several disks in a way that gives improved speed and full
capacity, but all data on all disks will be lost if any one disk fails.
• RAID 1 (mirrored settings/disks) duplicates data across every disk in the array, providing full
redundancy. Two (or more) disks each store exactly the same data, at the same time, and at all times.
Data is not lost as long as one disk survives. Total capacity of the array is simply the capacity of one
disk. At any given instant, each disk in the array is simply identical to every other disk in the array.
• RAID 5 (striped disks with parity) combines three or more disks in a way that protects data against loss
of any one disk; the storage capacity of the array is reduced by one disk.
• RAID 6 (striped disks with dual parity) (less common) can recover from the loss of two disks.
• RAID 10 (or 1+0) uses both striping and mirroring. "01" or "0+1" is sometimes distinguished from
"10" or "1+0": a striped set of mirrored subsets and a mirrored set of striped subsets are both valid, but
distinct, configurations.
• RAID 53 Merges the features of RAID level 0 and RAID level 3.
(Raid level 3 and Raid level 4 differs in the size of each drive.) This uses byte striping with parity merged
with block striping.
RAID can involve significant computation when reading and writing information. With traditional "real"
RAID hardware, a separate controller does this computation. In other cases the operating system or simpler
and less expensive controllers require the host computer's processor to do the computing, which reduces
the computer's performance on processor-intensive tasks (see "Software RAID" and "Fake RAID" below).
Simpler RAID controllers may provide only levels 0 and 1, which require less processing.
RAID systems with redundancy continue working without interruption when one, or sometimes more,
disks of the array fail, although they are then vulnerable to further failures. When the bad disk is replaced
by a new one the array is rebuilt while the system continues to operate normally. Some systems have to be
shut down when removing or adding a drive; others support hot swapping, allowing drives to be replaced
without powering down. RAID with hot-swap drives is often used in high availability systems, where it is
important that the system keeps running as much of the time as possible.
12

20. RAID Overview
RAID is not a good alternative to backing up data. Data may become damaged or destroyed without harm
to the drive(s) on which they are stored. For example, part of the data may be overwritten by a system
malfunction; a file may be damaged or deleted by user error or malice and not noticed for days or weeks;
and of course the entire array is at risk of physical damage.
Principles
RAID combines two or more physical hard disks into a single logical unit by using either special hardware
or software. Hardware solutions often are designed to present themselves to the attached system as a single
hard drive, so that the operating system would be unaware of the technical workings. For example, you
might configure a 1TB RAID 5 array using three 500GB hard drives in hardware RAID, the operating
system would simply be presented with a "single" 1TB disk. Software solutions are typically implemented
in the operating system and would present the RAID drive as a single drive to applications running upon
the operating system.
There are three key concepts in RAID: mirroring, the copying of data to more than one disk; striping,
the splitting of data across more than one disk; and error correction, where redundant data is stored to
allow problems to be detected and possibly fixed (known as fault tolerance). Different RAID levels use
one or more of these techniques, depending on the system requirements. RAID's main aim can be either to
improve reliability and availability of data, ensuring that important data is available more often than not
(e.g. a database of customer orders), or merely to improve the access speed to files (e.g. for a system that
delivers video on demand TV programs to many viewers).
The configuration affects reliability and performance in different ways. The problem with using more
disks is that it is more likely that one will go wrong, but by using error checking the total system can
be made more reliable by being able to survive and repair the failure. Basic mirroring can speed up
reading data as a system can read different data from both the disks, but it may be slow for writing if the
configuration requires that both disks must confirm that the data is correctly written. Striping is often used
for performance, where it allows sequences of data to be read from multiple disks at the same time. Error
checking typically will slow the system down as data needs to be read from several places and compared.
The design of RAID systems is therefore a compromise and understanding the requirements of a system is
important. Modern disk arrays typically provide the facility to select the appropriate RAID configuration.
Nested levels
Many storage controllers allow RAID levels to be nested: the elements of a RAID may be either individual
disks or RAIDs themselves. Nesting more than two deep is unusual.
As there is no basic RAID level numbered larger than 10, nested RAIDs are usually unambiguously
described by concatenating the numbers indicating the RAID levels, sometimes with a "+" in between.
For example, RAID 10 (or RAID 1+0) consists of several level 1 arrays of physical drives, each of which
is one of the "drives" of a level 0 array striped over the level 1 arrays. It is not called RAID 01, to avoid
confusion with RAID 1, or indeed, RAID 01. When the top array is a RAID 0 (such as in RAID 10 and
RAID 50) most vendors omit the "+", though RAID 5+0 is clearer.
• RAID 0+1: striped sets in a mirrored set (minimum four disks; even number of disks) provides fault
tolerance and improved performance but increases complexity. The key difference from RAID 1+0 is
that RAID 0+1 creates a second striped set to mirror a primary striped set. The array continues to operate
with one or more drives failed in the same mirror set, but if drives fail on both sides of the mirror the
data on the RAID system is lost.
• RAID 1+0: mirrored sets in a striped set (minimum four disks; even number of disks) provides fault
tolerance and improved performance but increases complexity. The key difference from RAID 0+1 is
13

21. RAID Overview
that RAID 1+0 creates a striped set from a series of mirrored drives. In a failed disk situation, RAID
1+0 performs better because all the remaining disks continue to be used. The array can sustain multiple
drive losses so long as no mirror loses all its drives.
• RAID 5+0: stripe across distributed parity RAID systems.
• RAID 5+1: mirror striped set with distributed parity (some manufacturers label this as RAID 53).
Non-standard levels
Many configurations other than the basic numbered RAID levels are possible, and many companies,
organizations, and groups have created their own non-standard configurations, in many cases designed to
meet the specialised needs of a small niche group. Most of these non-standard RAID levels are proprietary.
Some of the more prominent modifications are:
• Storage Computer Corporation uses RAID 7, which adds caching to RAID 3 and RAID 4 to improve
I/O performance.
• EMC Corporation offered RAID S as an alternative to RAID 5 on their Symmetrix systems (which is
no longer supported on the latest releases of Enginuity, the Symmetrix's operating system).
• The ZFS filesystem, available in Solaris, OpenSolaris, FreeBSD and Mac OS X, offers RAID-Z, which
solves RAID 5's write hole problem.
• NetApp's Data ONTAP uses RAID-DP (also referred to as "double", "dual" or "diagonal" parity),
which is a form of RAID 6, but unlike many RAID 6 implementations, does not use distributed parity
as in RAID 5. Instead, two unique parity disks with separate parity calculations are used. This is a
modification of RAID 4 with an extra parity disk.
• Accusys Triple Parity (RAID TP) implements three independent parities by extending RAID 6
algorithms on its FC-SATA and SCSI-SATA RAID controllers to tolerate three-disk failure.
• Linux MD RAID10 (RAID10) implements a general RAID driver that defaults to a standard RAID 1+0
with 4 drives, but can have any number of drives. MD RAID10 can run striped and mirrored with only
2 drives with the f2 layout (mirroring with striped reads, normal Linux software RAID 1 does not stripe
reads, but can read in parallel).[4]
• Infrant (Now part of Netgear) X-RAID offers dynamic expansion of a RAID5 volume without having
to backup/restore the existing content. Just add larger drives one at a time, let it resync, then add the next
drive until all drives are installed. The resulting volume capacity is increased without user downtime.
(It should be noted that this is also possible in Linux, when utilizing Mdadm utility. It has also been
possible in the EMC Clariion for several years.)
• BeyondRAID created by Data Robotics and used in the Drobo series of products, implements both
mirroring and striping simultaneously or individually dependent on disk and data context. BeyondRAID
is more automated and easier to use than many standard RAID levels. It also offers instant expandability
without reconfiguration, the ability to mix and match drive sizes and the ability to reorder disks. It is
a block-level system and thus file system agnostic although today support is limited to NTFS, HFS+,
FAT32, and EXT3. It also utilizes Thin provisioning to allow for single volumes up to 16TB depending
on the host operating system support.
14

22. Chapter 4. Solaris Security
BSM C2 Auditing
1. Fundamentals
The fundamental reason for implementing C2 auditing is as a response to potential security violations
such as NIMDA, Satan, or other attempts to compromise the integrity of a system. Secondary to that
reason, it can be used to log changes to a system, and tracking down questionable actions.
BSM C2 will not prevent the server from being compromised, however it does provide a significant
resource in determining if a server has been breached. Standard utilities such as “acct” cannot, nor
are they intended, to identify modifications, or connections to a server. Through the limited examples
described within this document it should be clear that the C2 module is capable of allowing Fidelity
Investments to clearly and quickly identify any potential compromise.
2. Tradeoffs
One tradeoff with running C2 as a consistent and active process is disk space consumption. The audit
trail it’s self contains status, date and time, and server within the filename, and the auditreduce command
allows for specifying a server name, which can be based on filename, or directory structure. This
identification within the file it’s self allows for placing a rotating copy of all audit trails on a central
repository server and for historical queries to be run which would not require logging in to a system,
except for currently written data. Properly deployed this can aid in meeting certain S.E.C. security
requirements by historically keeping audit trails on read only media once moved off of a system. Unlike
“acct” which tracks a process with some arguments, CPU cycles used per user, and logged in accounts,
C2 is designed to log all arguments, processes, connections, but not CPU % cycles – although this
information can be gathered through auditing. In addition to login information c2 can be used to track
user commands.
3. Audit Classes
In order to reduce the amount of logging not all classes are automatically enabled. The current C2
build module logs all users for lo, ex, and ad. However, the audit trail can be changed. Settings are
configured in the audit configuration file: /etc/security/audit_control and include success
& failure, success only, and failure only setting options. Each class, however, does not include, by
default, arguments or environmental variables.
Environmental and argument settings are configured in /etc/system/audit_startup
through the following commands:
#!/bin/sh
auditconfig –conf # change runtime kernel
# event-to-class mappings.
auditconfig -setpolicy argv # add command line arguments
auditconfig –setpolicy arge # add environmental variables
auditconfig -setpolicy +cnt # count how many audit records
# are dropped if > 20% free
Current Available Policies are as follows:
# auditconfig -lspolicy
policy string description:
15

23. Solaris Security
ahlt halt machine if it can not record an async event
all all policies
arge include exec environment args in audit recs
argv include exec command line args in audit recs
cnt when no more space, drop recs and keep a cnt
group include supplementary groups in audit recs
none no policies
path allow multiple paths per event
perzone use a separate queue and auditd per zone
public audit public files
seq include a sequence number in audit recs
trail include trailer token in audit recs
windata_down include downgraded window information in audit recs
windata_up include upgraded window information in audit recs
zonename generate zonename token
Class settings are located in /etc/security/audit_control and are in the following
format:
#!/bin/sh
dir:/fisc/bsm # location of audit trail
flags:lo,ex,ad # classes being audited for success and
# failure.
minfree:20 # Do not grow audit trails if less than
# 20% free
naflags:lo,ad # events that cannot be attributed to a
# particular user.
You can add the following as class attributes – be ware that more logging is more file system space
used. In many cases this should be custom setup depending on the server function, such as database,
application, or firewall.
Class Alias Description
no: nvalid class
fr: file read w file write
fa: file attribute access
fm: file attribute modify
fc: file create
fd: file delete
cl: file close
pc: process
nt: network
ip: pc na non-attribute ad administrative
lo: login or logout ap application
io: octl
ex: exec
ot: other
all: all classes
In addition each user can have their own audit trails custom fit. This is handled through the /etc/
security/audit_user file and has the following format:
# User Level Audit User File
16

24. Solaris Security
#
#
# username:always:never # root:lo:no
Individual users can have their audit trail adjusted to collect all possible data, but testing on each change
is vital. Any typo in /etc/security/audit_user can, and will, result in that users’ inability to
login. Each user can have their own audit trails custom fit.
This is handled through the /etc/security/audit_user file and has the following format:
# User Level Audit User File
#
#
# username:always:never
# root:lo:no myuser:lo:no
Individual users can have their audit trail adjusted to collect all possible data, but testing on each change
is vital. Any typo in /etc/security/audit_user can, and will, result in that users’ inability
to login.
BSM Secure Device Control
1. Fundamentals
Integrated within the BSM auditing module is the ability to allocate and restrict specific, user definable,
devices. The purpose of this level of restriction is to the following:
a. Prevent simultaneous access to a device.
b. Prevent a user from reading a tape just written to by another user, before the first user has removed
the tape from the tape drive.
c. Prevent a user from gleaning any information from the device’s or the driver’s internal storage after
another user is finished with the device
All descriptions below are with the default configuration. The devices configured by default can be
added to or removed from control via the device_allocate and device_maps file, however adding new
devices is a bit more complicated and will not be covered here.
2. Related files and commands
Files: /etc/security/device_allocate
/etc/security/device_maps,
/etc/security/dev/*
/etc/security/lib/*
Commands: list_devices, dminfo, allocate,
and deallocate
3. File descriptions and control features
/etc/security/device_allocate is used to associate specific devices, like st0 to RBAC roles
and cleanup scripts run at boot time.
audio;audio;reserved;reserved;solaris.device.allocate;
17

25. Solaris Security
/etc/security/lib/audio_clean
fd0;fd;reserved;reserved;solaris.device.allocate;
/etc/security/lib/fd_clean
sr0;sr;reserved;reserved;solaris.device.allocate;
/etc/security/lib/sr_clean
/etc/security/device_maps is a listing of devices
with alias names such as:
audio:
audio:
/dev/audio /dev/audioctl /dev/sound/0 /dev/sound/0ctl:
fd0:
fd:
/dev/diskette /dev/rdiskette /dev/fd0a /dev/rfd0a /dev/fd0b
/dev/rfd0b /dev/fd0c /dev/fd0 /dev/rfd0c /dev/rfd0:
sr0:
sr: /dev/sr0 /dev/rsr0 /dev/dsk/c0t2d0s0
/dev/dsk/c0t2d0s1 /dev/dsk/c0t2d0s2
/dev/dsk/c0t2d0s3 /dev/dsk/c0t2d0s4
/dev/dsk/c0t2d0s5 /dev/dsk/c0t2d0s6
/dev/dsk/c0t2d0s7 /dev/rdsk/c0t2d0s0
/dev/rdsk/c0t2d0s1 /dev/rdsk/c0t2d0s2
/dev/rdsk/c0t2d0s3 /dev/rdsk/c0t2d0s4
/dev/rdsk/c0t2d0s5 /dev/rdsk/c0t2d0s6
/dev/rdsk/c0t2d0s7
4. Converting root to a role and adding access to root role to a user
Fundamentals - login as a user and assume root; then modify the root account as type role and add the
root role to a user; test with fresh login before logging out
$ su -
# usermod -K type=role root
# usermod -R root useraccount
remote> ssh useraccount@host_with_root_role_config
$ su - root
#
5. Command review, and examples
Allocation is done by running specific commands, as well as deallocating the same device. Here are
a few examples.
# allocate –F device_special_filename
# allocate –F device_special_filename –U user_id
# deallocate –F device_special_filename
# deallocate –I
# list_devices –U username
6. Pulling it all together
18

26. Solaris Security
When combined a user with the RBAC role of solaris.device.allocate, can allocate fd0, sr0, and audit
devices – in essence hogging the device for themselves. The scripts referenced in the device_allocate
file are used to deallocate the device in the event of a reboot – this way no allocation would be persistent.
Since these files are customizable, it is possible to remove vold related devices such as the cdrom
mounting by just deleting that section.
Remember that device allocation is not needed for auditing to work, and can be set to allocate “nothing”
by stripping down the device_maps and device_allocate files – however more testing should be done
in this case.
General Hardening
1. IP Module Control IP module can be tuned to prevent forwarding , redirecting of packets and request
for information from the system . These parameters can be set using ndd with the given value to limit
these features .
# ndd -set /dev/ip ip_forward_directed_broadcasts 0
# ndd -set /dev/ip ip_forward_src_routed 0
# ndd -set /dev/ip ip_ignore_redirect 1
# ndd -set /dev/ip ip_ire_flush_interval 60000
# ndd -set /dev/ip ip_ire_arp_interval 60000
# ndd -set /dev/ip ip_respond_to_echo_broadcast 0
# ndd -set /dev/ip ip_respond_to_timestamp 0
# ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
# ndd -set /dev/ip ip_send_redirects 0
2. Prevent buffer overflows Add the following lines to /etc/system file to prevent the buffer
overflow in a possible attack to execute some malicious code on your machine.
set noexec_user_stack=1
set noexec_user_stack_log=1
Destructive DTrace Examples
Add /uid==300/ after syscall::uname:entry line to make this restricted to a response from UID 300.
#!/usr/sbin/dtrace -w -s
syscall::uname:entry{ self->a = arg0;}
syscall::uname:return{
copyoutstr("Windows", self->a,257);
copyoutstr("PowerPC", self->a+257,257);
copyoutstr("2010.b17", self->a(257*2),257);
copyoutstr("fud:2010-10-31", self->a+(257*3), 257);
copyoutstr("PPC, self->addr+(257*4),257);
}
Example changing uname output on a solaris system
#!/usr/sbin/dtrace -s
#pragma D option destructive
19

27. Solaris Security
syscall::uname:entry
{
self->addr = arg0;
}
syscall::uname:return
{
copyoutstr("SunOS", self->addr, 257);
copyoutstr("PowerPC", self->addr+257, 257);
copyoutstr("5.5.1", self->addr+(257*2), 257);
copyoutstr("gate:1996-12-01", self->addr+(257*3), 257);
copyoutstr("PPC", self->addr+(257*4), 257);
}
Before running the dtrace script:
# uname -a
SunOS homer 5.10 SunOS_Development sun4u sparc SUNW,Ultra-5_10
While running the dtrace script
# uname -a
SunOS PowerPC 5.5.1 gate:1996-12-01 PPC sparc SUNW,Ultra-5_10
Example killing a process when it trys to read a file
#cat read.d
#!/usr/sbin/dtrace -ws
ufs_read:entry
/ stringof(args[0]->v_path) == $$1 /
{
printf("File %s read by %dn", $$1, curpsinfo->pr_uid);
raise(SIGKILL);
}
# more /etc/passwd
Killed
# ./read.d /etc/passwd
dtrace: script './read.d' matched 1 probe
dtrace: allowing destructive actions
CPU ID FUNCTION:NAME
0 15625 ufs_read:entry File /etc/passwd read by 0
IPFilter Overview
1. Background With the release of Solaris 10, ipfilter is now supported. Before Solaris 10, EFS or
SunScreen Lite was the default firewall. IPfilter is a mature product traditionally found in BSDish
Operating Systems
2. Configure an ippool if list of firewalled hosts is large enough - use /etc/ipf/ippool.conf
# /etc/ipf/ippool.conf
# IP range for China
20

28. Solaris Security
table role = ipf type = tree number = 5
{
219.0.0.0/8;
220.0.0.0/8;
222.0.0.0/8;
200.0.0.0/8 ;
211.0.0.0/8;
};
# IP Range for proplem hosts
table role = ipf type = tree number = 6
{
66.96.240.229/32;
125.65.112.217/32;
77.79.103.219/32;
61.139.105.163/32;
61.160.216.0/24;
};
# IP Range for internal network
table role = ipf type = tree number = 7
{ 192.168.15.0/24; } ;
# IP Range for known information stealers
table role = ipf type = tree number = 8
{
209.67.38.99/32;
204.178.112.170/32;
205.138.3.62/32;
199.95.207.0/24;
199.95.208.0/24;
216.52.13.39/32;
216.52.13.23/32;
207.79.74.222/32;
209.204.128.0/18;
209.122.130.0/24;
195.225.177.27/32;
65.57.163.0/25;
216.251.43.11/32;
24.211.168.40/32;
58.61.164.141/32;
72.94.249.34/32;
};
3. Configuring IPF First, you will need an ipf ruleset. The Solaris default location for this file is /etc/
ipf/ipf.conf. Below is the ruleset I used for a Solaris 10 x86 workstation. Note that the public NIC
is called elx10. Simply copy this ruleset to a file called /etc/ipf/ipf.conf, and edit to your needs.
# /etc/ipf/ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
21

29. Solaris Security
# IP Filter rules syntax.
#
# Public Network. Block everything not explicity allowed.
block in log on bge0 all
block out log on bge0 all
#
# Allow all traffic on loopback.
pass in quick on lo0 all
pass out quick on lo0 all
#
# Allow pings out.
pass out quick on bge0 proto icmp all keep state
#
#
pass in log quick on bge0 proto tcp from any to 192.168.15.78/24
port = 8080
pass in log quick on bge0 proto tcp from any to 192.168.15.78/24
port = 443
pass in log quick on bge0 proto tcp from any to 192.168.15.78/24
port = 22
# Internal Hosts
pass in quick from pool/7 to 192.168.15.78
# Blocked due to showup in IDS
block in log quick from pool/6 to any
# Block Asia APNIC Inbound
block in log quick on bge0 proto tcp/udp from pool/5 to any
# Block Asia APNIC Outbound
block out log quick on bge0 proto tcp/udp from any to pool/5
#
# Known information stealers
block in log quick from pool/8 to any
block out log quick from any to pool/8
# Allow outbound state related packets.
pass out quick on bge0 proto tcp/udp from any to any keep state
#
Table 4.1. Common IPFilter Commands
Command Line Description
ipf -E Enable ipfilter when running : for the first time. :
(Needed for ipf on Tru64)
ipf -f /etc/ipf/ipf.conf Load rules in /etc/ipf/ipf.conf file : into
the active firewall.
ipf -Fa -f /etc/ipf/ipf.conf Flush all rules, then load rules in : /etc/ipf/
ipf.conf into active firwall.
ipf -Fi Flush all input rules.
ipf -I -f /etc/ipf/ipf.conf Load rules in /etc/ipf/ipf.conf file : into
inactive firewall.
ipf -V Show version info and active list.
ipf -s Swap active and inactive firewalls.
22

30. Solaris Security
Command Line Description
ipfstat Show summary
ipfstat -i Show input list
ipfstat -o Show output list
ipfstat -hio Show hits against all rules
ipfstat -t -T 5 Monitor the state table and refresh every : 5
seconds. Output is similar to : 'top' monitoring the
process table.
ipmon -s S Watch state table.
ipmon -sn Write logged entries to syslog, and : convert back
to hostnames and servicenames.
ipmon -s [file] Write logged entries to some file.
ipmon -Ds Run ipmon as a daemon, and log to : default
location. : (/var/adm/messages for Solaris) : (/var/
log/syslog for Tru64)
IPSec with Shared Keys
Note
Information collected from http://www.cuddletech.com/
Creating Keys
Using the ipsecalgs command we can see the available algorithms, including DES, 3DES, AES, Blowfish,
SHA and MD5. Different alogithms require different key lengths, for instance 3DES requires a 192 bit
key, whereas Blowfish can use a key anywhere from 32bits up to 448 bits.
For interoperability reasons (such as OSX or Linux), you may with to create keys that are both ASCII and
hex. This is done by choosing a string and converting it to hex. To know how long a string should be,
divide the number of bits required by 8, this is the number of ASCII chars you need. The hex value of
that ASCII string will be double the number of ASCII chars. Using the od utility we can convert ASCII-
to-hex. Here I'll create 2 keys, one for AH which is a SHA1 160bit key (20 ASCII chars) and another for
ESP which is a Blowfish 256bit key (32 ASCII chars):
benr@ultra ~$ echo "my short ah password" | od -t x1
0000000 6d 79 20 73 68 6f 72 74 20 61 68 20 70 61 73 73
0000020 77 6f 72 64 0a
0000025
benr@ultra ~$ echo "this is my long blowfish esp pas" | od -t x1
0000000 74 68 69 73 20 69 73 20 6d 79 20 6c 6f 6e 67 20
0000020 62 6c 6f 77 66 69 73 68 20 65 73 70 20 70 61 73
0000040 0a
0000041
my short ah password
6d792073686f72742061682070617373776f7264
this is my long blowfish esp pas
23

31. Solaris Security
74686973206973206d79206c6f6e6720626c6f77666973682065737020706173
Configuring IPsec Policies
IPsec policies are rules that the IP stack uses to determine what action should be taken. Actions include:
• bypass: Do nothing, skip the remaining rules if datagram matches. drop: Drop if datagram matches.
• permit: Allow if datagram matches, otherwise discard. (Only for inbound datagrams.)
• ipsec: Use IPsec if the datagram matches.
As you can see, this sounds similar to a firewall rule, and to some extent can be used that way, but you
ultimately find IPFilter much better suited to that task. When you plan your IPsec environment consider
which rules are appropriate in which place.
IPsec policies are defined in the /etc/inet/ipsecinit.conf file, which can be loaded/reloaded using the
ipsecconf command. Lets look at a sample configuration:
benr@ultra inet$ cat /etc/inet/ipsecinit.conf
##
## IPsec Policy File:
##
# Ignore SSH
{ lport 22 dir both } bypass { }
# IPsec Encrypt telnet Connections to 8.11.80.5
{ raddr 8.11.80.5 rport 23 } ipsec
{ encr_algs blowfish encr_auth_algs sha1 sa shared
Our first policy explicitly bypasses connections in and out ("dir both", as in direction) for the local port
22 (SSH). Do I need this here? No, but I include it as an example. You can see the format, the first curly
block defines the filter, the second curly block defines parameters, the keyword in between is the action.
The second policy is what we're interested in, its action is ipsec, so if the filter in the first curly block
matches we'll use IPsec. "raddr" defines a remote address and "rport" defines a remote port, therefore
this policy applies only to outbound connections where we're telnet'ing (port 23) to 8.11.80.5. The second
curly block defines parameters for the action, in this case we define the encryption algorithm (Blowfish),
encryption authentication algorithm (SHA1), and state that the Security Association is "shared". This is
a full ESP connection, meaning we're encrypting and encapsulating the full packet, if we were doing AH
(authentication only) we would only define "auth_algs".
Now, on the remote side of the connection (8.11.80.5) we create a similar policy, but rather than "raddr"
and "rport" we use "laddr" (local address) and "lport" (local port). We could even go so far as to specify
the remote address such that only the specified host would use IPsec to the node. Here's that configuration:
## IPsec Policy File:
##
# Ignore SSH
{ lport 22 dir both } bypass { }
# IPsec Encrypt telnet Connections to 8.11.80.5
{ laddr 8.11.80.5 lport 23 } ipsec
{ encr_algs blowfish encr_auth_algs sha1 sa shared }
24

32. Solaris Security
To load the new policy file you can refresh the ipsec/policy SMF service like so: svcadm refresh ipsec/
policy. I recommend avoiding the ipsecconf command except to (without arguments) display the active
policy configuration.
So we've defined policies that will encrypt traffic from one node to another, but we're not done yet! We
need to define a Security Association that will association keys with our policy.
Creating Security Associations
Security Associations (SAs) can be manually created by either using the ipseckeys command or directly
editing the /etc/inet/secret/ipseckeys file, I recommend the latter, I personally find the
ipseckeys shell very intimidating.
Lets look at a sample file and then discuss it:
add esp spi 1000 src 8.15.11.17 dst 8.11.80.5 auth_alg sha1
authkey 6d792073686f72742061682070617373776f7264 encr_alg
blowfish encrkey 6d792073686f72742061682070617373
add esp spi 1001 src 8.11.80.5 dst 8.15.11.17 auth_alg sha1
authkey 6d792073686f72742061682070617373776f7264 encr_alg
blowfish encrkey 6d792073686f72742061682070617373
It looks more intimidating that it is. Each line is "add"ing a new static Security Association, both are for
ESP. The SPI is the "Security Parameters Index", is a simple numeric value that represents the SA, nothing
more, pick any value you like. The src and dst define the addresses to which this SA applies, note that you
have two SA's here, one for each direction. Finally, we define the encryption and authentication algorithms
and full keys.
I hope that looking at this makes it more clear how policies and SA's fit together. If the IP stack matches
a datagram against a policy who's action is "ipsec", it takes the packet and looks for an SA who's address
pair matches, and then uses those keys for the action encryption.
Note that if someone obtains your keys your hosed. If you pre-shared keys in this way, change the keys
from time-to-time or consider using IKE which can negotiate keys (and thus SAs) on your behalf.
To apply your new SA's, flush and then load using the ipseckeys command:
$ ipseckey flush
$ ipseckey -f /etc/inet/secret/ipseckeys
Is it working? How to Test
All this is for nothing if you don't verify that the packets are actually encrypted. Using snoop, you should
see packets like this:
$ snoop -d e1000g0
Using device e1000g0 (promiscuous mode)
ETHER: ----- Ether Header -----
ETHER:
ETHER: Packet 1 arrived at 9:52:4.58883
ETHER: Packet size = 90 bytes
ETHER: Destination = xxxxxxxxxxx,
ETHER: Source = xxxxxxxxxx,
ETHER: Ethertype = 0800 (IP)
ETHER:
25

33. Solaris Security
IP: ----- IP Header -----
IP:
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: .... ..0. = not ECN capable transport
IP: .... ...0 = no ECN congestion experienced
IP: Total length = 72 bytes
IP: Identification = 36989
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 61 seconds/hops
IP: Protocol = 50 (ESP)
IP: Header checksum = ab9c
IP: Source address = XXXXXXXXX
IP: Destination address = XXXXXXXXXXXX
IP: No options
IP:
ESP: ----- Encapsulating Security Payload -----
ESP:
ESP: SPI = 0x3e8
ESP: Replay = 55
ESP: ....ENCRYPTED DATA....
And there you go. You can no encrypt communication transparently in the IP stack. Its a little effort to get
going, but once its running your done... just remember to rotate those keys every so often!
IPSec With 509 Certs
1. first you have to ensure, that the names of the systems can be resolved. It´s a good practice to put the
names of the systems into the /etc/hosts:
::1 localhost loghost
127.0.0.1 localhost loghost
10.211.55.201 gandalf
10.211.55.200 theoden
2. Okay, we don´t want manual keying or some stinking preshares keys. Thus we need to create keys.
Login to gandalf and assume the root role:
$ ikecert certlocal -ks -m 1024 -t rsa-md5 -D
"C=de, O=moellenkamp, OU=moellenkamp-vpn, CN=gandalf"
-A IP=10.211.55.201
Creating private key.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
26