Sun System Controller

8/6/2019 Sun System Controller

1/62

Sun Microsystems, Inc.901 San A ntonio Road

Palo Alto, CA 94303 USA650 960-1300 fax 650 969-9131

http://www.sun.com/blueprints

Securing the

Sun Fire Midframe

System Controller

Updated for SCapp 5.13, Solaris 8 (2/02),

and Solaris 9

A lex Noordergraaf andTonyM. Benson,

Enterprise Server Products

Sun BluePrints OnLine - June, 2002

Part No .: 816-4940-10

Revision 01, 6/ 3/ 02

Edition: June 2002


2/62

0 June 2002

Copyright 2002 Sun Microsystems, Inc.,4150N etwork Circle, Santa Clara, California 95054,U.S.A.All rights reserved.

Sun Microsystems,Inc. has intellectual prop erty rights relating to technology emb odied in the prod uct that is described in thisdocum ent. In particular, and withou t limitation, these intellectual prop erty rights may include one or more of the U.S. patents listed athttp :/ / www.sun.com/ p atents and one or more additional patents or pending pa tent applications in the U.S.an d in other coun tries.

This docum ent and the produ ct to which it pertains are distributed und er licenses restricting their use, copying, distribution, anddecomp ilation.N o part ofth e product or ofthis documen t may be reprod uced in any form by any means without prior writtenauth orization of Sun and its licensors, if any.

Third-party software, including font technology, is copyrighted an d licensed from Sun sup pliers.

Parts of the prod uct may be derived from Berkeley BSD systems, licensed from the University of California. UNIXis a registeredtradem ark in the U.S. and in other countries, exclusively licensed through X/ Open Compa ny,Ltd .

Sun, Sun Microsystems, the Sun logo, AnswerBook2, docs.sun.com, Solaris, Sun Fire, Sun BluePrints, Solaris Security Toolkit, SunCluster,Sun Enterp rise, Solaris Operating Environment, JumpStart, SunPS, Sun Remote Services Net Connect, Sun Remote ServicesEvent Monitoring, SUNSOLVEO NLINE, Solaris Secure Shell,N etra T1,Sun Swift,Sun Quad FastEthernet, OpenBoot, and SunManagem ent Center are trademarks or registered tradem arks ofSun Microsystems, Inc.in the U.S. and in other coun tries.

All SPARC tradema rks are used un der license and are tradem arks or registered tradema rks of SPARC International, Inc. in the U.S.and in other countr ies.Prod ucts bearing SPARC trademark s are based up on an architecture developed by Sun Microsystems, Inc.

The OPEN LOOK and Sun Graph ical User Interface was developed by Sun Microsystems, Inc.for its users and licensees. Sunacknowled ges the pioneering efforts ofXerox in researching and d eveloping the concept ofv isual or graphical user interfaces for thecompu ter indu stry.Sun h olds a non -exclusive license from Xerox to the Xerox Graph ical User Interface,w hich license also coversSuns licensees wh o implement OPEN LOOK GUIs and otherw ise comp ly with Suns written license agreements.

Use, du plication, or disclosure by the U.S.Govern ment is subject to restrictions set forth in the Sun Microsystems, Inc.licenseagreem ents and as provided in DFARS227.7202-1(a) and 227.7202-3(a) (1995), DFARS 252.227-7013(c)(1)(ii)(Oct. 1998), FAR12.212(a)(1995), FAR 52.227-19, or FAR 52.227-14(ALT III), as applicable.

DOCUMEN TATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CON DITIONS, REPRESENTATIONS AN DWARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHAN TABILITY, FITNESSFOR A PARTICULAR PURPOSE ORNON -INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO TH E EXTENT TH AT SUCH DISCLAIMERSARE H ELD TO BE LEGALLYINVALID.

Copyright 2002Sun Microsystems, Inc.,4150N etwork Circle, Santa Clara, California 95054, Etats-Unis.Tous droits rservs.

Sun Microsystems,Inc. a les droits de prop rit intellectuels relatants la technologie incorpore dans le produ it qui est dcrit dans cedocum ent. En particulier, et sans la limitation, ces droits de prop rit intellectuels peu vent inclure un ou plus des brevets amricainsnum rs http :/ / ww w.sun.com/ paten ts et un ou les brevets plus supp lmentaires ou les app lications de brevet en attente dan s lesEtats-Unis et dan s les autres pays.

Ce produit ou docum ent est protg par un copyright et distribu avec des licences qui en restreignent lutilisation, la copie, ladistribution, et la dcompilation. Aucune partie de ce produit ou d ocument ne peut tre reproduite sous aucune forme,p arquelquemoyen q ue ce soit,san s lautorisation p ralable et crite de Sun et de ses bailleurs de licence, sil y ena.ls

Le logiciel dtenu par d es tiers, et qui comprend la technologie relative aux polices de caractres,est protg par u n copyright etlicenci par des fourn isseurs de Sun.

Des parties de ce prod uit pou rront tre d rives des systmes Berkeley BSD licencis par lUniversit de Californie.UN IXest un emarqu e dpose aux Etats-Unis et dan s dautres pays et licencie exclusivement pa r X/ Op en Compa ny,Ltd .

Sun, Sun Microsystems, le logo Sun, AnswerBook2, docs.sun.com, Solaris Sun Fire,Sun BluePrints, Solaris Security Toolkit, SunCluster,Sun Enterp rise, Solaris Operating Environment, JumpStart, SunPS, Sun Remote Services Net Connect, Sun Remote ServicesEvent Monitoring, SUNSOLVEO NLINE, Solaris Secure Shell,N etra T1,Sun Swift,Sun Quad FastEthernet, OpenBoot, et SunManagem ent Center sont des marqu es de fabrique ou des marqu es dposes de Sun Microsystems, Inc.a ux Etats-Unis et dan sdautres pays.

Toutes les marqu es SPARC sont utilises sous licence et sont des marqu es de fabrique ou des m arques d poses de SPARCInternational, Inc. aux Etats-Unis et dans dautres pays. Les prod uits protant les marques SPARC sont bass sur une architecturedvelop pe par Sun Microsystems,Inc.

Linterface dutilisation graph ique OPEN LOOKet Sun a t dveloppe par Sun Microsystems, Inc. pou r ses utilisateurs etlicencis.Sun reconnat les efforts de pionn iers de Xerox pou r la recherche et le dveloppm ent d u concept d es interfaces dutilisationvisuelle ou grap hique p our lindustrie d e linformatique. Sun d tient une license non exclusive do Xerox sur linterface dutilisationgrap hique Xerox,cette licence couvrant galement les licencies de Sun qu i mettent en place linterface d utilisation graph ique OPENLOOK et qui en outre se conforment aux licences crites de Sun .


3/62

1

Securing the Sun Fire MidframeSystem Controller

This article provid es recomm end ations on h ow to securely dep loy the Sun Firemidframe system controller (SC). These recomm end ations app ly to environments

where security is a concern, particularly environments where the uptime

requirements of the SC and / or the information on the Sun Fire server is critical to

the organization.

Many issues are involved in securing the Sun Fire SC. The most significant is its use

of insecure a dm inistrative p rotocols. In add ition, it is sensitive to som e typ es of

network-based attacks such as Denial of Service (DoS) attacks.

The recomm enda tions in this article includ e building a separa te and private SC

network, to w hich the insecure protocols required to m anage an SC are restricted. A

midframe service p rocessor (MSP) is the secure gatew ay into the p rivate SC

network. A d etailed, sup ported , and secured MSP configuration is described.

This article contains the following topics:

s About the Authors on page 57

s Updates on p age 2

s Background Information on page 2

s Securing th e System Controller on p age 13

s Building a Secure MSP on page 28

s Backing Up, Restoring, and Upd ating the SC on p age 45

s Resetting a Platform Adm inistrators Lost Password on page 53

s Verifying H arden ing Results on page 56

s

Related Resources on page 58


4/62

2 Securing the Sun Fire Midframe System Controller June 2002

UpdatesThis Sun BluePrints OnLine article is updated for the Solaris 8 (2/ 02) Operating

Environment, version 5.13.0 of the SC application, and version 23 of the SC Real

Time Operating System (RTOS). The recommendations in this article should apply to

all SC app lication 5.13 releases.

The main chang es are in the SC:

s The peek an d poke comman ds available in th e interactive SC power on self test

(SCPOST) facility can now be disabled by a write-protect jumper on the SC board.

s The Telnet service can be disabled. If it is enabled, then a session idle timeout can

be set.

s The showplatform an d showdomain comman ds n ow indicate the syslogfacility.

s BugId 4417940, which affected the operation ofsetkeyswitch secure mode,

was fixed.

s Network ports 68, 111, and 1024 are disabled on the SC.

s Sup port for SC failover is introdu ced.

s Sup port for Simple N etwork Time Protocol (SNTP) is introduced to the SC.

Backgrou nd InformationThe following sections provide helpful information for u nd erstanding the SC, MSP,

hard ware an d software requiremen ts, and other top ics. This section contains the

following topics:

s Assumptions and Limitations on page 3

s Obtaining Support on page 5

s System Controller (SC) on page 5

s Midframe Service Processor (MSP) on page 10


5/62

Background Information 3

Assum ptions and Limitations

In this article, our recomm end ations are based on several assum ptions and

limitations as to w hat can be d one to secure a Sun Fire system controller (SC) using

a midframe service processor (MSP) configuration.

Our recommen da tions assume a platform based on Solaris 8 Operating Environmen t

(2/ 02), version 5.13.0 of the SC app lication, and version 23 of the SC Real Time

Operating System (RTOS).

Solaris Operating Environment (Solaris OE) hard ening can be interpreted in man y

ways. For purposes of developing a hardened MSP configuration, we address

hard ening all possible Solaris OE options. That is, anyth ing that can be h arden ed is

hardened. When there are good reasons for leaving services and daemons as they

are, we d o not harden or modify them.

Note Be aw are that hard ening Solaris OE configurations to the level described in

this article may not be ap prop riate for your en vironment. For some environments,

you m ay w ant to perform fewer hard ening operations than recommend ed. The

configuration remains sup ported in these cases; how ever, add itional hard ening

beyond what is recommended in this article is not supported.

The recommend ed Solaris OE cluster is End User. While it wou ld be p ossible to

install the MSP w ith significantly fewer Solaris OE p ackages, it is not a su pp orted

configuration. Only Solaris OE hard ening tasks described in this article are

sup ported configurations for the MSP.

Note Stand ard security rules app ly to hardening Sun Fire SCs and MSPs: Thatwhich is not specifically permitted is denied.

When a dd ressing security of the MSPs, we focus on MSP fun ctionality inherent in or

required by MSP servers. We do n ot ad dress security for non-MSP servers run ning

Solaris 8 OE. For recommendations on generic Solaris OE security configuration,

refer to other sources such as the security-related Sun BluePrints OnLine articles.

In this article, we omit ad ditional software that you can install on the MSP, such as

SunSM Remote Services Event Monitoring, Sun Remote Services N et Conn ect, and

Sun Management Center software.


6/62


Qualified Software Versions

The configuration discussed in this article has the following software installed.

System Controller

s SC app lication v ersion 5.13.0

s SC Real Time O per ating System (RTOS) version 23

Midframe Service Processor

s Solaris 8 OE (2/ 02) installed with the End User Cluster

s Latest Security and Recommended Patch Cluster from SUNSOLVESM ONLINE

Web sites OpenSSH

s Solaris Security Toolkit version 0.3.6

s FixModes software

s MD5 software

Note The use of Solaris 9 OE and its bundled version of Solaris Secure Shell is

sup ported for use on the MSP.

Minimum MSP System RequirementsWe cannot m ake specific recommend ations of the hard ware requ irements because

they dep end extensively on the num ber of SCs supp orted by an MSP, in ad dition to

the software being ru n on the MSP. For examp le, if the MSP is runn ing only the

software d escribed in this article for several SCs, then a system such as the N etra

T1 server wou ld be recommen ded . Alternatively, if the MSP is runn ing ad ditional

monitoring and man agement software for several hund red SCs, then a significantly

larger server would be recommended.

The minimum hard ware an d software recommen ded for an MSP is as follows:

s Sun4U architecture

s 8-GByte d isk

s 128-MByte RAM

s CD-ROM d rive

s SunSwift card or, ideally, a Sun Quad FastEthernet card

s Solaris 8 O E


7/62


8/62


Because only one p assword , belonging to th e platform ad ministrator, is needed to

control the machine, it is critical that insecure protocols required to man age the SC

be limited to a private and highly-secured n etwork; referred to as th e private SCnetwork throug hou t the rest of this documen t. To limit these protocols to one

network segment, a gateway system is needed to provide an access and control

point. This gateway system should have at least two netw ork interfaces. One

interface connects to the private SC network , and the other to the gen eral access

intranet or man agement network.

This gateway system, referred to as th e m idframe service processor (MSP), is a

server on which encrypted and strongly-authenticated management services (for

example, SSH, IPsec, and SNMPv2usec) can be installed. Administrators log into the

MSP using the en crypted p rotocols. The insecure and n on-encrypted p rotocols

should only be used on the p rivate SC network. If the p rivate SC network is built on

physically separate network devices (for example, no VLANs) there is little exposure

to network sniffing or oth er network -based attacks. The recommen dations for the

placement are built on top of the recommend ations mad e in the Sun BluePrints

OnLine article titled Building Secure N -Tier Environments .

Domain an d SC Isolation an d Comm un ication

The Sun Fire midframe h ardw are architecture w as d esigned to enforce strict

separation between domains and limited communication between the domains and

SC. However, there must exist a comm un ication path betw een each dom ain and the

SC so that the SC can provid e a virtu al console for each dom ain, access to the

Open Boot Prom (OBP), and a mechan ism for services and daem ons to

commu nicate from the SC to the domains an d d omains to the SC. This

commu nication p ath w as carefully constru cted to enforce the separation of doma ins

and SC, and to ensure that information cannot be leaked between domains or from

one dom ain to another through the SC. The following p aragrap hs provide ad ditional

information on how this communication path was designed and implemented to

provide separation between the domains and SC.

The SP communicates with a domain and the domain with the SC via reading and

writing to the static random access memories (SRAM) located on the Inpu t/ Outpu t

(I/ O) and CPU board s.

The I/ O board SRAM is accessible to CPUs in the dom ain throu gh a PCI interface.

Access to the SRAM on the CPU boards is p rovided by a local interface on those

boards. It is not possible for a dom ain to u se either of these mechanisms to access

SRAM located on hardware in other domains. The SC is able to access all SRAMs in

the Sun Fire midframe chassis over a separate hard ware p ath called the console bus.

An en tire SRAM is not d edicated to this commu nication chan nel. The SC specifies

which SRAM and location within that SRAM is to be used during domain startup.

Specifically, the SP provides this information to domain during its power on self test


9/62


(POST) sequence. POST then passes this information to the OpenBoot Prom (OBP)

which then passes it on to Solaris OE. In this way the SC is able to define the SRAM

to be used and the portion thereof.

Before passing SRAM information to OBP, the SC is responsible for initializing the

data stru ctures to be used. Different d ata structures are used for the portions of

SRAM used to communicate between the SP and POST, the SP on OBP, and the SP

and Solaris. These different m emory structures are referred to as m ailboxes. These

mailboxes provide a bi-directional commun ication path between th e different

components on the domain and SP.

By imp lementing inter-chassis comm un ications, strict sep aration is m aintained

between d omains on a Sun Fire midframe. In add ition, commu nication to the SP is

strictly limited and does not provide a general purpose connection that could be

used to either comp romise the SP or leak information throu gh the SP to another

domain.

Failover

System controller failover is described in the Sun Fire 6800/4810/4800/3800 Platform

Administration Manual and the Sun Fire 6800/4810/4800/3800 System Controller

Command Reference Manual.

The configuration and operation of the SC for failover is not within the scope of this

article. However, if the SC is configured for failover, then we recomm end that y ou

use SNTP for synchronization of the system clocks. Refer to Use the SNTP Default

Configuration on p age 20.

Terminal Server Usage

We strongly recomm end that you use a term inal server that sup ports the u se of SSH

to encrypt sessions. This recomm end ation is made because th e terminal server is not

on the p rivate SC network , but on th e general pu rpose intranet. If Telnet is used to

access the terminal server, then all passw ords are pa ssed over the gen eral purp ose

network, in clear text. This insecure transmission d efeats ma ny of the security

measu res designed into the architecture. Terminal servers sup porting SSH a re

available from Cisco Systems, Perle, and oth er vend ors.


10/62


11/62


Access to Engineering M ode is protected by a password. These passwords are only

good for a period of time. Passwords are gen erated internally by Sun on an as

needed basis, and as such are not generally available.

Note Improper use ofEngineering Mode can damage hardware, override or change

any aspect of SC behavior, and lead to breaches of platform security.

Service Mod e

The platform adm inistration sh ell can be operated in a special restricted m ode

known as Service Mode. This mod e was introdu ced w ith version 5.13.0 of the SC

application. Service Mode is for use b y Sun service staff, and is not sup ported for use

under any other circumstance.

Access to Service Mode is protected by a password. It does not share the same

password as Engineering Mode, but the passw ord m anagem ent is similar. The

passw ord is only good for a period of time. Passwords are generated internally by

Sun on an as needed basis, and as such are not generally available.

Note Improper use ofService Mode can dam age hardw are, override or change

aspects of SC behavior, and lead to breaches of platform security.

Write-Protect Jumper

The SC contains several erasable p rogramm able read only m emories (EPROMs)

one of w hich contains the RTOS image. This EPROM is associated with a w rite-

protect jump er (labeled J1303). The jum per h as tw o positions, write-protect and

write-enable. The factory setting for this jump er is th e w rite-enable p osition. The

jum per is bridged in the w rite-enable position.

In the wr ite-enable position, the RTOS image can be u pd ated u sing the

flashupdate command.

Some organ izations may h ave security policies that require a high d egree of

protection against the risk of improp er access to the RTOS. Where su ch a

requirement exists, you can use the w rite-protect jum per to p rovide p rotection.

In the w rite-protect position, the following features are d isabled:

s flashupdate

s Control-A and Control-X comman ds

s peek an d poke comman ds in interactive SCPOST mod e


12/62


Be aw are of the following special considerations for u sing the write-protect jum per:

s To change the p osition of the write-protect jum per, the SC mu st be remov ed from

the chassis. Only trained p ersonnel are allowed to perform this procedu re.

s When u pd ates are required for the RTOS, it is necessary to pow er dow n an d

remove the SC to change the jumper configuration both before and after the RTOS

update.

s During a n RTOS upd ate, while the EPROM is not w rite-protected, app ropriate

measures must be taken to avoid unauthorized access to the console serial port.

s It is recommended that the platform be configured with a redundant SC, using

the SC failover feature to avoid Sun Fire frame d own time.

For instru ctions and add itional information, refer to the Sun Fire 6800/4810/4800/3800

Platform A dministration Manual and the Sun Fire 6800/4810/4800/3800 System

Controller Command Reference Manual.

Midframe Service Processor (MSP)

A mid frame service processor (MSP) is a separate comp onent th at you can use to

provide services to th e Sun Fire SC. In ad dition to oth er services, these services

includ e the following:

s encrypted access point (for SSH, IPsec, or alternative)

s SYSLOG server

s flash u pd ate services

s dumpconfig an d restoreconfig services

s secure choke point separating SC netw ork traffic from genera l pur pose intranetnetwork traffic

We recommend that you configure the SC to use an external MSP server. For an

example of the n etwork top ology of an SC and an MSP server, refer to FIGURE 1 on

page 29.

An SC can function withou t an external server such as the MSP, however, some SC

functionality an d monitoring capabilities are not available. These includ e flash

up dates to th e SC EPROMs, SYSLOG message logging, and configuration backup

through dumpconfig. These functions are critical to the ongoing m aintenance and

man agement of a Sun Fire platform.

Because the MSP is used as a secure access mechanism between gen eral pur pose

networks an d p rivate SC networks, the MSP should n ot be used for any other tasks.For examp le, an MSP should not be given ad ditional tasks as a general pu rpose N FS

server.


13/62


Note The MSP shou ld be d edicated to the task of isolating a nd protecting th e SCs

from malicious network and user access.

The most secure MSP has the least software installed an d the fewest services and

adm inistrator accoun ts. The m ore secure the MSP, the better the protection provided

for the Sun Fire SC.

This recommendation does not mean that you cannot install additional software on

the MSP. How ever, any a dd itional software shou ld be restricted to that wh ich is

required to monitor and/ or manage the MSP. The MSP is a critical system because it

controls access and the flow of information to and from the SC. The MSP should be

man aged ba sed on th e requirements of the organization. For examp le, in an

enterprise where enterpr ise backup software is used to backup system s, it would be

appropriate and prudent to install the required software on the MSP. Conversely, it is

not a good practice to use the MSP as a general purp ose web server. Evaluate thepotential security impact of add itional software to ensu re that th e overall security of

the MSP is not ad versely affected.

Mapp ing to Mu ltiple SCs

Depending on the architecture of an environment, it may be desirable to support

several SCs from one MSP. This configuration is recommended, from a security

persp ective, as long as all the systems (MSP and SCs) are within one administrative

domain.

An administrative domain is a group of systems that are managed by the same or

cooperating organizations, perform similar functions, and operate at similar security

levels. For example, an ad ministrative domain m ay includ e all the da tabase servers

in a d ata center. In this situation, one MSP, or a p air of MSPs, wou ld be a pp ropriate

to man age as man y of the Sun Fire database servers as need ed. This administrative

dom ain mu st not includ e the Internet-accessible web servers that access the d atabase

servers. Because the web servers are exposed to a significantly greater risk of misuse,

they are in a different administrative domain and should be managed by a separate

MSP.


14/62


Fault Toleran ce

The MSP topology d escribed in th is article places the MSP as a single po int of failurefor accessing the SC over Telnet connections, storing SYSLOG files, and other

functions of the MSP. Single points of failure ad versely affect uptime and shou ld be

avoided wh erever possible. Several options are av ailable to m itigate some of the

risks.

The simplest op tion is use IP mu ltipath ing (IPMP). This option p rovides link-level

redu nd ancy for failures in the network cables, network sw itch p ort failures, or a

failure of the Q FE card port. This option does not p rotect against more significant

hard ware failures on the MSP.

Additional redundancy can be obtained by having a cold spare available to replace

the MSP if a serious failure occurs. This spare system w ould be fully configured as

the MSP, or msp01 in this article; how ever, it would not be p owered on. This

configuration m inimizes most of the dow ntime associated with fixing the p rimarysystem, because a replacement system is already configured and available; it just

needs to be powered on when the failed system is powered off.

The most fault resistant configuration wou ld be to cluster two MSPs. The clustering

software could then automatically fail over the MSP services from one MSP server to

the oth er in th e even t of a failure. To not lose access to log files, SYSLOG output, and

other d ata files on the MSP, the two systems w ould have to sha re a disk su bsystem.

Obviously, wh ile this system provides the h ighest availability, it is also the most

complicated. Add ressing h ow th is type of a configuration could imp act the security

postu re of the SC is beyond the scope of this article.


15/62

Securing the System Controller 13

Securing the System ControllerWhen the p latform an d d omains of the SC are configured , make sure to configure

them securely. Some of the tasks are performed by the platform ad ministrator, wh ile

others are performed by the appropriate domain administrator.

This article focuses on the SC configuration chan ges required to secure the SC.

Normal administrative issues are addressed only when they are impacted by a

security modification. For full details on configuring the SC, refer to the system

controller publications listed in Related Resources on page 58.

Note Implement the security m odifications imm ediately after the Sun Fire RTOS

and SC app lication has been flashed w ith the latest firmwa re upd ates and b efore anySun Fire dom ains are configured or installed.

Always u se the most recent u pd ates available from SUNSOLVE ONLINE Web site.

Securing th e SC consists of performing th e following tasks:

s Configuring Platform Adm inistrator Settings on p age 14

s Rebooting th e SC to Imp lement Settings on page 24

s Configuring Domain Ad ministrator Settings on p age 25

Caution We recommend that you disable the SC failover mechanism before

hard ening the SCs. Re-enable failover only after you h arden and test the entire

configuration.


16/62


Configuring Platform Ad ministrator Settings

Most of the platform ad ministrator setting configurations are performed through the

setupplatform comman d. You can ru n this comman d either in an interactive

mod e wh ere it asks specific questions or a non -interactive mode by specifying the

configuration m odification requ ired. For the pu rposes of this article, we ru n th e

command in non-interactive mode by using the -p option.

To secure the SC, perform the following tasks:

s Configure N etwork Settings on page 14

s Configure th e Platform Loghost on p age 15

s Define Platform Password on p age 16

s Define Domain Passw ord on page 17

s Choose Method for Managing Networked Devices on page 18

s Use the SNTP Default Configura tion on p age 20

s Define H ardw are Access Control Lists (ACLs) on page 21

s Configure Telnet on page 23

Configure Network Settings

The first task in setting u p a n SC is to enable networking. This task d efines wh ether

the system u ses dyna mic or static IP add resses, wh at its hostname is, its IP address,

DNS server, and other n etwork information.

In this secured topology, we u se static IP ad dresses. Dynam ic host configuration

protocol (DHCP) is certainly an option and a DHCP server could be set u p an dpopulated with the appropriate MAC and hostname information for the SCs on the

MSP. However, the effort required to set up and man age the DH CP server is

app ropriate only if there are man y SCs to configure.

If you use DH CP, configure the DH CP server to p rovide services only for the private

SC network and no other network segments.

All networ k traffic to the SC is routed throu gh th e MSP. Because IP forwar ding is not

enabled on the MSP, all the packets mu st be p roxied th rough the MSP. As an

add itional security measure, this practice allows u s to not sp ecify a default router on

the SC.

For network-based nam e resolution, the SC requires a DN S server. In this secured

environmen t, this requirement is not n ecessary, because th e only system the SCcommunicates with is the MSP. Consequently, no DNS server information is entered

wh ile configuring the SC.


17/62


We used the following comman d to en ter the changes on the SC:

Configure the Platform Loghost

The next task in configuring the SC is to configure the p latform loghost to w hich all

SYSLOG messages are forward ed. The SC has no local disk, so it cannot store these

messages locally. They mu st be forward ed to a central location for storage,

reconciliation, and review (for u nu sual activity). If DNS is not being u sed, you mu st

take care to define the loghost through the IP add resses. In our examp le, DNS is not

being used, so we enter the IP address.

In add ition to specifying the n ame/ IP add ress of the loghost, the facility level

included in the SYSLOG messages can be sp ecified. The SYSLOG protocol provides

eight user-defined facility levels: local0 through local7, in ad dition to the 18

system-defined facilities. However, only the user-defined facility levels can be used

wh ile custom izing the SCs SYSLOG behavior.

All SC generated SYSLOG messages come from the sam e IP add ressthat of the SC.

The different SYSLOG facilities mu st be used to d istingu ish between m essages

originated from the platform an d each d omain. For examp le, the platform wou ld use

th e SYSLOG facility local0, wh ile domain-a would u se the SYSLOG facility

local1, and so on.

sc0:SC> setupplatform -p network

Network Configuration

---------------------

Is the system controller on a network? [yes]: yes

Use DHCP or static network settings? [dhcp]: static

Hostname [unknown]: ds7-sc0

IP Address [0.0.0.0]: 192.168.100.20

Netmask [0.0.0.0]: 255.255.255.0

Gateway [0.0.0.0]:

DNS Domain [none]: none

Primary DNS Server [0.0.0.0]:

Secondary DNS Server [0.0.0.0]:

Rebooting the SC is required for changes in network settings to

take effect.


18/62


The MSP is fun ctioning a s the SYSLOG server, so we en ter its IP add ress in the

following manner with the corresponding SYSLOG facility level (local0) for the

platform:

Details on how to configure the SYSLOG service on the MSP are provided in

Configuring the MSP SYSLOG on page 43.

Use the showplatform comman d to d isplay the loghost and log facility for the

platform:

Define Platform Password

The next task is to set the p latform p assword . The only restrictions on SC platform

and domain passwords are the character set supported by ASCII and the terminal

emu lator in use. The SC uses the MD5 software to generate a h ash of the p assword

entered. Correspon dingly, all characters entered are significant.

A minimum passw ord length of 16 characters is recomm end ed to prom ote the use of

pass-phrases instead of passwords. Passwords should be comprised of at least

lowercase, up percase, numeric, and p un ctuation mark s. Given th e capabilities of

current systems to either bru te-force access or guess encrypted passw ords, an eight

character length string is no longer secure.

The following command sets the platform shell password:

ds7-sc0:SC> setupplatform -p loghost

Loghosts

--------

Loghost [ ]: 192.168.100.10

Log Facility [local0]: local0

ds7-sc0:SC> showplatform -p loghost

Loghost for Platform: 192.168.100.10

Log Facility for Platform: local0

ds7-sc0:SC>password

Enter new password: xxxxxxxxxxxxxxxxEnter new password again: xxxxxxxxxxxxxxxx


19/62


20/62


If a passw ord w as defined for either a p latform or d omain shell, the pa ssword

comman d requ ires its entry before allowing a new p assword to be entered. The only

exception to this is that the platform administrator can change a domain passwordwithou t know ing the old p assword with th e release of 5.13 as follows:

Choose Method for Managing N etworked Devices

Simple Netw ork Managem ent Protocol (SNMP) is comm only used to monitor and

man age netw orked d evices and systems. Early versions of SNMP, such as SNMPv1

and SNMPv2, suffer from security issues because they d ont ad dress issues such as

auth entication, data integrity checks, and encryption. Upd ated versions of the

protocol are proposed, su ch as SNMPv2usec and SNMPv3, yet are not fully

app roved by the IETF, the organization that controls these standard s. For more

information, refer to Related Resources on page 58.

While the full specification of SNMPv2usec d oes ad dress m any of the limitations ofthe SNMPv1 and v2 protocols, certain comp onents of SNMPv2usec (such as

encryption for privacy) are optional an d not requ ired for SNMPv2usec comp atibility.

The Sun Fire SC only supp orts the u se of SNMPv1. Due to th is limitation, we m ake

the following recomm end ations for choosing a meth od of monitoring and m anaging

networked devices.

ds7-sc0:SC> console d

Enter Password:

Connected to Domain D

Domain Shell for Domain D

ds76-sc0:D> disc

Connection closed.

ds7-sc0:SC>password -d d

Enter new password:

Enter new password again:


21/62


Using Sun Management Center Software

You can use Sun Man agement Center 3.0 (Sun MC) software to man age an dmaintain your Sun Fire midframe systems. To u se Sun MC 3.0 securely, we

recommend , in ad dition to u sing SNMPv2usec capabilities, that you isolate all of its

management traffic to a physically isolated and dedicated management network.

This recommendation is based on the network segmentation recommendations

presented in the Sun BluePrints OnLine article titled Building Secure N -Tier

Environments.

Sun MC requires platform agen t software to m anage th e Sun Fire midframe SC. We

recommend that you install the software on either the Sun MC server or a separate

server. Do not connect the system to the public intranet. Limit access to the platform

agent software by not installing it on the MSP.

If isolating the Sun MC server to a completely separate and isolated n etwork is not

possible, then install the p latform agent software on a separa te system. This serverrequires at least two network interfaces. One connects to the pr ivate SC network and

the other connects to a private man agement n etwork, connecting it to the Sun MC

server.

Regardless of where the p latform agent software is installed, the en tire network from

the SC to the Sun MC server mu st be a physically separated and ded icated n etwork.

Hard en and secure all add itional servers, including th e Sun MC server.

Disabling SM N P

The alternative is to disable SNMP on the SC and n ot use an y SNMP-based

man agemen t prod ucts. This option provid es protection against all possible SNMP-

based attacks. It should be n oted, how ever, that d isabling these services on the SC

prevents SNMP-based man agement tools from mana ging the SunFire SC.

Disable the SNMP d aemon on the SC as follows:

ds7-sc0:SC> setupplatform -p snmp

SNMP

----

Platform Description [Serengeti-24 P1.2]:

Platform Contact [ppb]:

Platform Location []:

Enable SNMP Agent? [yes]: no

May 16 20:59:36 ds7-sc0 Chassis-Port.SC: Stopping SNMP agent.


22/62


Use the SNTP Default Configura tion

The default SC configuration for SNTP is off, and we recommend that youconfigure it to on, so that you can u se SNTP.

Simple Network Time Protocol (SNTP), described in RFC 2030, is an adaptation of

the Network Time Protocol (NTP), described in RFC 1305, and is used to

synchronize comp uter clocks. SNTP d oes not change the N TP specification; rather it

clarifies certain design features of NTP to allow operation in a simple, stateless

remote-procedure call (RPC) mod e. SNTP clients su ch as th e Sun Fire mid frame SC

can interoperate with existing NTP or SNTP clients and servers. SNTP is intended to

be used only at the extremities of the time synchronization su bnet.

A full description of how to architect and imp lement a time synchronization su bnet

is out of the scope of this document. We recommend that you understand the

concepts described in the following Sun BluePrints OnLine articles:

s Using NTP to control and Synchronize System Clocks - Part I: Introduction to NTP

s Using NTP to control and Synchronize System Clocks - Part II: Basic NTP

Admin istration and A rchitecture

s Using NTP to Control and Synchronize System Clocks - Part III: NTP Monitoring and

Troubleshooting

If configured for SNTP, the SC sends a request to a designated SNTP or NTP unicast

server and expects a reply from th at server. The SC does n ot implemen t the op tional

authentication method specified in RFC 1305. The SC neither accepts remote

adm inistration comm and s via SNTP, nor d oes it accept an y broad cast traffic.

Because the SC SNTP client uses port 123 UDP w ithout a uthen tication, it is not

difficult to spoof the designated NTP or SNTP server; therefore, the SC is vulnerable

to a port 123 DoS attack.

The use of RPC-based SNTP introdu ces another reason w hy th e SCs mu st be isolated

to a ph ysically separate n etwork. We recomm end that the MSP be used as the SNTP

server for the SC. How ever, it is imp ortant th at the MSP be configured to secure its

NTP traffic as described in the previously mentioned Sun BluePrints OnLine articles.

The configuration an d operation of the SC for failover is not w ithin the scope of this

article. If you want to configure the SC for failover, then we recommend that you use

SNTP for synchron ization of the system clocks. For d etails, refer to the Sun Fire 6800/

4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800

System Controller Command Reference Manual.


23/62


Define H ard ware Access Control Lists (ACLs)

This task app lies and is imp ortant only if the Sun Fire server has mu ltiple dom ainsand their resources are restricted in som e way. Only when these conditions are

present should ACLs be implemented.

By d efault, all hardw are present in the system is accessible to all dom ains. In ou r

example, a Sun Fire 6800 server is divided into three dom ainswhere each dom ain

has one CPU and I/ O board.

Use the platform ad ministrator shell to assign the d ifferent CPU and I/ O boards into

the app ropriate domains.

Note ACLs only limit hardw are assignm ents mad e while using the domain shells.

Hardware assignments made while using the platform shell supersede all ACL

definitions.

The capability of the platform shell to assign an d reassign hard ware comp onents is

not restricted by ACLs. We recommend that the p latform ad ministrator account be

used initially only to assign hard ware compon ents to the approp riate domain. After

hardware components are assigned to each domain, the administrators should log

into the app ropriate dom ain shell account to manage the hardware assigned to that

dom ain. The remaind er of this section provides a sam ple implementa tion of our

recommendations.

First, we use the following command to determine which boards are present:

ds7-sc0:SC> showboard

Slot Pwr Component Type State Status

---- -- ------------- ---- -----

SB0 On CPU Board Available Passed



IB6 On PCI I/O Board Available Passed




24/62


We view the curren t set of ACLs defined on the system w ith the following

commands:

We assign the resources to the appropriate domains with the following commands:

We use th e showboard command to produ ce the following outpu t:

ds7-sc0:SC> showplatform -p acl

ACL for Domain A: SB0 SB2 SB3 IB6 IB7 IB8

ACL for Domain B: SB0 SB2 SB3 IB6 IB7 IB8

ACL for Domain C: SB0 SB2 SB3 IB6 IB7 IB8

ACL for Domain D: SB0 SB2 SB3 IB6 IB7 IB8

ds7-sc0:SC> addboard -d a SB0 IB6

ds7-sc0:SC> addboard -d b SB2 IB8

ds7-sc0:SC> addboard -d c SB3 IB7

ds7-sc0:SC> showboard

Slot Pwr Component Type State Status Domain

---- -- ------------- ---- ----- ------

/N0/SB0 On CPU Board Assigned Passed A

/N0/SB2 On CPU Board Assigned Passed B

/N0/SB3 On CPU Board Assigned Passed C

/N0/IB6 On PCI I/O Board Assigned Passed A

/N0/IB7 On PCI I/O Board Assigned Passed C/N0/IB8 On PCI I/O Board Assigned Passed B


25/62


As a final verification, we check th e ou tpu t from setupplatform an d

showplatform commands, which appears as follows for our example:

Now three domains, a through c, are defined on ou r Sun Fire server; each with on e

CPU and I/ O board.

Note Although a platform ad ministrator can assign hardw are into specific

dom ains, it is up to d omain ad ministrators to use those resources approp riately and

determine whether those resources are configured into a running domain.

Hardware already assigned to a running domain is not removed if its ACL is

mod ified to restrict it from being u sed in that d omain. Therefore, it is importan t toassign hard ware into d omains as soon as it is available in the chassis and before

domain administrators assign it.

Configure Telnet

The Telnet service on th e SC is enabled by d efault. You can define the session idle

timeout p eriod that app lies to all Telnet connections to th e SC. The default is no

session idle timeout period. The Telnet configuration does not affect the operation of

the p latform console.

Based on th e configuration in this article, we recommend that Telnet timeouts be

enabled to a value app ropriate for your organization. This pra ctice allows Telnetsessions to be established from the MSP. Refer to the Sun Fire 6800/4810/4800/3800

System Controller Command Reference Manual for details on how to configure Telnet

timeouts.

ds7-sc0:SC> setupplatform -p acl

ACLs

----

ACL for domain A [ SB0 SB2 SB3 IB6 IB7 IB8 ]: sb0 ib6

ACL for domain B [ SB0 SB2 SB3 IB6 IB7 IB8 ]: sb2 ib8

ACL for domain C [ SB0 SB2 SB3 IB6 IB7 IB8 ]: sb3 ib7

ACL for domain D [ SB0 SB2 SB3 IB6 IB7 IB8 ]:

ds7-sc0:SC> showplatform -p acl

ACL for Domain A: SB0 IB6

ACL for Domain B: SB2 IB8ACL for Domain C: SB3 IB7

ACL for Domain D:


26/62


If the SC is on a general purp ose network, then we recommen d tha t you d isable the

Telnet service and restrict access to SSH-enabled terminal server access.

To disable the Telnet service, use the setupplatform -p security command as

follows:

For add itional instru ctions, refer to the Su n Fire 6800/4810/4800/3800 S ystem Controller

Command Reference Manual.

Rebooting the SC to Implement Settings

If needed , reboot the SC to implement y our configuration settings. The SC has to be

rebooted only if a console message similar to the following is displayed:

To reboot the SC, enter the following comman d from the p latform sh ell:

Note The SC can be rebooted while domains are up and running.

After rebooting the SC, use the showplatform command to validate that all the

mod ifications are implemented .

ds7-sc0:SC> settupplatform -p security

Security Options ---------------- Enable telnet servers? [yes]: no

Idle connection timeout (in minutes; 0 means no timeout) [0]:

ds7-sc0:SC>

Rebooting the SC is required for changes in network settings to

take effect.

ds7-sc0:SC> reboot -y


27/62


Configuring Domain Administrator Settings

After all of the platform shell configuration m odifications are m ade, imp lement the

dom ain-specific configuration m odifications. Most of the recomm end ed changes are

performed using the platform shell.

Only a few dom ain-specific changes require u sing dom ain shells. These

modifications are as follows:

s Setting the Loghost and facility for each domain

s Setting the SNMP information

Each of these mu st be d efined ind ividually for each d omain. The following sam ples

show th ese changes for domain-a.

Define a Loghost

You m ust d efine a Loghost for each of the d oma ins ind ividu ally. The configura tion is

similar to th at in the Configure th e Platform Loghost on p age 15. In ad dition, we

recommend that you use a facility un ique to the frame. By having sep arate

definitions of Loghost for each dom ain and platform shell, you can use sep arate

SYSLOG servers to collect information. In this secured network environmen t, only

one system collects and p arses the SYSLOG datathe MSP. The facility option helps

differentiate SYSLOG messages coming from the four different dom ains and platform

shells.

Before using th e setupdomain comman d to d efine the Loghost for each dom ain, log

into the appropriate domain shell.

We perform the following to set our example domain-a shell Loghost to be th e MSP:

In our example, the Loghost d efinition d efines a facility oflocal1. Previously, the

platform shell used local0. This examp le is specific to domain-a. Correspond ingly,

domain-b uses local2, domain-c uses local3, and domain-d uses local4.

ds7-sc0:A> setupdomain -p loghost

Loghosts

--------

Loghost [ ]: 192.168.100.10

Log Facility for Domain A: local1


28/62


Note The dom ain shell definition of Loghost has no effect on w here the SYSLOG

messages generated by a Solaris OE image running on that domain are forwarded.Define the Solaris OE SYSLOG server in the /etc/syslog.conf configuration file

of the Solaris OE.

For information abou t how to configure the SYSLOG service on the MSP, refer to

Configuring the MSP SYSLOG on p age 43.

Use the showdomain comman d to d isplay the Loghost and Log Facility for the

domain:

Configure Domain SNMP Information

Each d omain h as un ique SNMP configurations that m ust be configured separately.

Some of the d omain SNMP information can be th e same (for examp le, dom ain

contact and trap host); however, the public and private community strings must be

different for each d omain. Different p ublic and p rivate commu nity strings are

required so that each d omain can be accessed separately. The tw o commu nity strings

provide the mechanism by which individual domains are accessed.

In our secured configuration, the SNMP d aemon w as disabled in the p latform sh ell.

Correspond ingly, it is unnecessary to set the pu blic and p rivate commun ity strings,

because we are n ot using SNMP.

If SNMP management or monitoring is used, then non-default SNMP community

strings mu st be selected.

Configure Domain setkeyswitch

The setkeyswitch comman d provides fun ctionality similar to the p hysical key

setting on the Sun Enterpr ise server line. When a Sun Enterprise server is

functioning, th e keyswitch shou ld be in the secure setting. With a Sun Fire server,

there is no ph ysical key to turn , so this fun ctionality is provided with the

setkeyswitch command from the platform and domain shells.

The recommended setkeyswitch setting for a running domain is secure. This

setting is very similar to th e setkeyswitch on position, with a few ad ditional

restrictions. Most importantly, in the secure setting, the ability to flash u pd ate the

ds7-sc0:A> showdomain -p loghost

Loghost for Domain A: 192.168.100.10

Log Facility for Domain A: local1


29/62


CPU/ Memory and I/ O boards is disabled. Flash up dating these board s should on ly

be don e by an ad ministrator wh o has d omain shell access on the SC. If the

adm inistrator has dom ain shell access, then using setkeyswitch to change fromsecure to on is straightforward. Administrators without domain and/ or platform

access cannot perform this command.

We use the following comm and to set our examp le domain-a into secure mode:

You can d isable two other Sun Fire domain features by u sing the setkeyswitch

secure option. When a domain is running in secure mod e, it ignores break an d

reset commands from the SC. This practice is not only an excellent precaution from

a security persp ective, it also ensu res that an accidently issued break or reset

comman d d oes not halt a running d omain.

Restricting SC OS Access

Some organ izations have security p olicies that requ ire a high d egree of protection

against the risk of improp er access to the RTOS. Where such a requ irement exists,

you can use the w rite-protect jum per to p rovide p rotection. For more information

about the jump er, refer to Write-Protect Jump er on page 9.

Although th e jum per p rovides a higher degree of protection, be advised tha t using it

requires add itional m aintenance effort. When u pd ates are required for the RTOS, a

qualified, trained p erson mu st power d own th e system and remov e the SC to chan ge

the jump er configuration both b efore and after the RTOS up date.

In configurations w ith a single SC, this task results in platform d own time. For this

reason, we recommend that the platform be configured with a redundant SC, using

the SC failover feature to a void Sun Fire frame d own time.

For more details about configuring the SC failover feature, refer to the Sun Fire 6800/

4810/4800/3800 Platform Administration Manual and the Sun Fire 6800/4810/4800/3800

System Controller Command Reference Manual.

During an RTOS up date, wh ile the EPROM is not w rite-protected, app ropriate

measures must be taken to avoid unauthorized access to the console serial port.

ds7-sc0:A> setkeyswitch secure


30/62


Build ing a Secure MSPThe MSP (midframe service processor) is the gatew ay between general pu rpose

internal networks a nd the p rivate SC network . As such, it controls access between

these netw orks. To effectively protect it against u nau thorized access, harden it and

implement encrypted access mechanisms.

Hard ening is critical to the security of the SC because the d efault configuration of

Solaris OE does not provide the requ ired p rotection for the MSP.

The recommended Solaris OE installation for the MSP is the End User Cluster rather

than the Developer, Entire Distribution, or OEM Installation Clusters. Using the End

User Cluster significantly red uces the nu mber of Solaris OE p ackages installed on

the MSP.

Hard ening the MSP consists of performing the following tasks:

s Configuring Netw ork Topology on page 29

s Installing Ap ache Web Server on page 30

s Add ing Security Software on page 34

s Installing Down loaded Software and Implementing Mod ifications on p age 40

s Configuring the MSP SYSLOG on p age 43

In our example, we use th e Solaris Security Toolkit software and the FixModes

software to secure the MSP. The Solaris Security Toolkit implements

recommend ations ma de in the Sun BluePrints On Line security articles. These

recommend ations are docum ented in th e following articles:s Solaris Operating Environment Security: Updated for the Solaris 8 Operating

Environment

s Solaris O perating Environment N etwork Settings for Security: U pdated for S olaris 8

Operating Environment

s The Solaris Security Toolkit - Installation, Configuration, and Usage Guide: Updated for

version 0.3

Note You can bu ild the MSP either through an interactive CD-ROM-based or

Solaris JumpStart installation. The Solaris Security Toolkit software can be used in

either type of installation. Refer to the Sun BluePrints OnLine article The Solaris

Security Toolkit - Quick Start: Updated for Version 0.3 .


31/62

Building a Secure MSP 29

Configuring Network Topology

Configure the SC on a p rivate SC network, u sing the MSP as a non-routing gatew ay

to provide a secure access mechanism between general purpose networks and the

private SC network.

In this section, we show a samp le network top ology containing one Sun Fire 6800

server, two SCs, and one MSP. You can extrap olate othe r architectures from t his

samp le design. The systems in th is topology are as follows:

s msp01

s sc0

s sc1

s domain-a

s domain-b

s domain-c

s domain-ds nts01

FIGURE 1 shows a logical diagram and does not include all of the components

required to make this samp le environment function. Specifically, the netw ork

switches required are not addressed. We recommend that you use separate network

switches for the private SC network instead of VLANs on a larger switch. Whichever

switch you use for the private SC network, we recommend that the switch be

managed and monitored the same w ay as other switches in the environment.

FIGURE 1 Sample Network Topology Configuration

The network d iagram illustrates the sep arate network s we u se to isolate the SC from

general network traffic. The general network (192.168.0.0/ 24) is not routed to the

private SC network (192.168.100.0/ 24), because IP Forwarding is disabled on the

MSP.

domain-a domain-b domain-c domain-d

sc0

sc1

nts01(Serial Connections)

192.168.100/24Private SC

Network

msp01

General Purpose Network (192.168.0.0/24)

.20 .21 .22 .23

.21

.20

.10

.10

.11


32/62


Two access mechan isms are ava ilable to connect to th e SC in this netw ork

architecture:

s An administrator can SSH to the MSP (msp01 in the diagram), then Telnet from it

to the SC.

s An ad ministrator can use th e serial connection accessible from the netw ork

terminal server (nts01 in the diagram ) as an alternative access mechanism to th e

SC. In this topology, even when the MSP is not available the SC is accessible

through the network terminal server.

Installing Apache Web Server

In the configuration documented in this article, the MSP uses the Apache Web Server

to perform Solaris Web Start Flash up dates of the SC EPROMs and to prov ide

restoreconfig with a tran sport m echanism to restore SC backups created w ithdumpconfig.

Other w eb servers can be u sed on the MSP, instead of the Ap ache Web server.

How ever, only the recommend ed Ap ache configuration is described in this article.

The Apache d istribution a vailable in Solaris 8 OE is not installed w ith the End User

Cluster, therefore, it ma y be n ecessary to m anu ally install the three requ ired Ap ache

packages. If Apache is already installed on your MSP, some of the following step s

may not be necessary.

w To Install the Apache Web Server

1. Obtain the required packages f rom any Solaris 8 OE 2 of 2 CD-ROM, dated 4/01,

in the f ollow ing di rectory:

The three requ ired Solaris 8 OE Apache Web Server packages are as follows:

#pwd

/cdrom/sol_8_401_sparc_2/Solaris_8/Product

system SUNWapchd Apache Web Server Documentation

system SUNWapchr Apache Web Server (root)

system SUNWapchu Apache Web Server (usr)


33/62


2. Create a tar file containing these three packages in the follow ing m anner:

3. Move the tar file to the MSP, extract it, and install it using the following

commands:

4. Answer Yes to all the questions asked.

5. After the installation i s completed, use the pkginfo | grep Apache command

to verify that all three required Apache Web Server packages are p resen t.In the next steps, youll create an ap prop riate user and group ID for Apache to run

as .

6. Create a new g roup by adding the fol lowi ng line to the /etc/group file:

The example uses a group ID of 15 for mspstaff. If this group ID is already used in

your en vironment, select a group ID that is not being used .

7. Create a user account for the Apache daemon.

The following examp le uses msphttp:

8. For all administrators who need access to files shared by Apache, add their user

IDs to the end of the mspstaff entry in the /etc/group file.

Before starting the Ap ache da emon, you mu st configure it. Only a few steps a re

required to do that.

9. Create an httpd.conf file using the following command:

# tar -cvf /tmp/apache-pkgs.tar SUNWapchd SUNWapchr SUNWapchu

# tar -xf apache-pkgs.tar

#pkgadd -d . SUNWapchd SUNWapchr SUNWapchu

mspstaff::15:

# /usr/sbin/useradd -m -g mspstaff msphttp

11 blocks

#pwd

/etc/apache

# cp httpd.conf-example httpd.conf


34/62


10. Open the /etc/apache/httpd.conf file in an editor and se arch for the

following line:

11. Add the follow ing line i mmediately after it.

Where the IP add ress is the IP ad dress of the MSP on the pr ivate SC network :

This step configures the Ap ache Web Server to respond only to connection requests

from the private SC network and not to the general purpose network. This

configuration is importan t because other systems m ust n ot be able to access the

information that is m ade available over HTTP to the SC.

A few other Ap ache configuration mod ifications are still required. The Apa che Web

Server mu st be told w hat nam e to use. Because the nam e of the MSP on the p rivate

SC networ k may not be resolvable, this configuration u ses the IP add ress of that

interface.

12. Search for the follow ing lin e in the /etc/apache/httpd.conf file:

13. Add the follow ing line i mmediately after it.

Where the IP add ress is the IP ad dress of the MSP on the pr ivate SC network :

The Apache Web Server mu st be told w hat d irectory structure to m ake available.

This directory is called the DocumentRoot and should be the top-most directory of

wh ere the Flash archives and backup files are kept.

14. Search for the follow ing lin e in the /etc/apache/httpd.conf file:

#Listen 12.34.56.78:80

Listen 192.168.100.10:80

#ServerName new.host.name

ServerName 192.168.100.10

DocumentRoot "/var/apache/htdocs"


35/62


36/62


20. Start the Apache Web Server with the following command:

The Apache Web server is now ready to function as a restoreconfig server and

can be used as a flashupdate server.

Ad ding Security Software

The next stage in harden ing an MSP requires dow nloading an d installing ad ditional

software security packages. This section covers the following tasks:

s Install Solaris Security Toolkit Software on p age 34

s Download Recommended Patch Cluster Software on page 35

s Down load FixModes Software on page 37

s Down load Op enSSH Software on p age 38

s Download the MD5 Software on page 39

Note Of the software described in this section, the Solaris Security Toolkit,

Recomm end ed and Security Patch Cluster, FixModes, and MD5 software are

required. Instead of Op enSSH, you can substitute a commercial version of SSH,

available from a variety of vend ors. You mu st install an SSH prod uct on the MSP.

Install Solaris Security Toolkit Software

The Solaris Security Toolkit software must be downloaded first, then installed on the

MSP. Later, youll use the Solaris Security Toolkit software to automate installing

other security software and implementing the Solaris OE mod ifications for

hard ening th e MSP.

The prima ry fun ction of the Solaris Security Toolkit software is to au tomate a nd

simplify bu ilding secured Solaris OE systems based on the recomm end ations

contained in this and other security-related Sun BluePrints OnLine articles.

Note The following instructions use filenames th at are correct on ly for version0.3.6 and later of the Solaris Security Toolkit software.

# /etc/init.d/apache start

httpd starting.


37/62


w To Dow nload Solaris Secu rity Toolkit Softw are

1. Dow nload the latest version o f the source file.

At the time of this pu blication, the version is SUNWjass-0.3.6.pkg.Z. The source

file is located at:

http://www.sun.com/security/jass

2. Extract the s ource file into a di rectory on the se rver using the uncompress

command :

3. Install the Solaris Security Toolkit software onto the server using the pkgadd

command:

Executing this comman d creates the SUNWjass subd irectory in /opt. This

subd irectory contains a ll Solaris Secur ity Toolkit directories an d a ssociated files. The

script make-pkgincluded in Solaris Security Toolkit software releases since

version 0.3allows ad ministrators to create custom packages u sing a d ifferent

installation directory.

Down load Recomm end ed Patch Cluster Software

Patches are regularly released by Sun to p rovide Solaris OE fixes for performance,

stability, functionality, and security. It is critical to the security of a system that the

most up-to-date patch is installed. To ensure that the latest Solaris OE Recommended

and Security Patch Cluster is installed on the MSP, this section describes how to

dow nload th e latest patch cluster.

Down loading th e latest patch cluster does not requ ire a SUNSOLVE ONLINE

program su pport contract.

Note Apply standard best practices to all patch installations. Before installing any

patches, evaluate and test them on non-production systems or during scheduled

maintenance wind ows.

# uncompress SUNWjass-0.3.6.pkg.Z

#pkgadd -d SUNWjass-0.3.6.pkg SUNWjass


38/62


w To Dow nload Recomm end ed Patch Cluster Softw are

1. Do wn load the latest patch from the S UN SOLVE ONLINE Web si te at:

http://sunsolve.sun.com

2. Click on the Patches link at the top of the left navigation bar.

3. Select the appropriate Solaris OE version in the Recommended Solaris Patch

Clusters box.

In our example, we select Solaris 8 OE.

4. Sele ct the best do wn load op tion, eithe r HTTP or FTP, wi th the associated radio

button, then click Go.

A Save As dialog box is displayed in you r browser w indow.

5. Save the file locally.

6. Move the file securely to the MSP w ith the scp command, or ftp if scp is not

available.

The scp command used should be similar to the following:

7. Move the file to the /opt/SUNWjass/Patches directory and uncompress it as

follows:

Later, using the Solaris Security Toolkit software, youll install the patch after

downloading all the other security packages.

Note If you d o not place the Recommended and Security Patches software into the/opt/SUNWjass/Patches directory, a warning m essage displays wh en you

execute the Solaris Security Toolkit software.

% scp 8_Recommended.zip msp01:/var/tmp

# cd /opt/SUNWjass/Patches

#mv /var/tmp/8_Recommended.zip .# unzip 8_Recommended.zip

Archive: 8_Recommended.zip

creating: 8_Recommended/

inflating: 8_Recommended/CLUSTER_README

inflating: 8_Recommended/copyright

inflating: 8_Recommended/install_cluster

[. . .]


39/62


Download FixModes Software

FixModes is a software p ackage that tightens the d efault Solaris OE directory andfile p ermissions. Tightening these p ermissions can significantly imp rove ov erall

security of the MSP. More restrictive permissions make it even more difficult for

malicious u sers to gain privileges on a system.

w To Download FixModes Software

1. Dow nload the FixModes pre-compiled bi naries f rom:

http://www.sun.com/blueprints/tools/FixModes_license.html

The FixModes software is distributed as a p recompiled and compressed tar file

formatted for systems based on SPARC. The file name is FixModes.tar.Z.

2. Once downloaded, move the file securely to the MSP with the scp command, or

ftp if scp is no t available.

The scp command used should be similar to the following

3. Save the file, FixModes.tar.Z, in the Solaris Security Toolkit Packages

directory in /opt/SUNWjass/Packages.

The following comm and s perform these tasks:

Caution Leave the file in its comp ressed state.

Later, using the Solaris Security Toolkit software, youll install the FixModes

software after dow nloading all the other security packages.

% scp FxiModes.tar.Z msp01:/var/tmp

# cd /opt/SUNWjass/Packages

#mv /var/tmp/FxiModes.tar.Z .


40/62


41/62


Caution Do not comp ile OpenSSH on the MSP and d o not install the comp ilers on

the SC. Use a separate Solaris OE systemrunning the sam e Solaris OE version,architecture, and mode (for example, Solaris 8 OE, Sun4U, and 64 bit)to compile

Open SSH. If you implement a comm ercial version of SSH, then no comp iling is

required.

Download the MD5 Software

The MD5 software validates MD5 digital fingerprints on the MSP. Validating the

integrity of Solaris OE binaries provid es a robu st mechan ism to d etect system

binaries that are altered or trojaned (hidden inside something that appears safe) by

un auth orized u sers. By mod ifying system binaries, attackers provide them selves

with back-door access onto a system; they hide their presence and cause systems tooperate in un stable m anners.

w To Inst all the MD5 Softw are (Intel an d SPARC)

1. Download the MD5 binaries from the following web site:

http://www.sun.com/blueprints/tools/md5_license.html

The MD5 program s are distributed as a comp ressed tar file.

2. Move the file md5.tar.Z securely to the MSP with the scp command, or ftp if

scp is n ot available.

The scp command used should be similar to the following:

3. Copy the file, md5.tar.Z, to the So laris Security Toolk it Packages directory in

/opt/SUNWjass/Packages

Caution Do not un compress the tar archive.

After the MD5 software is saved to the /opt/SUNWjass/Packages directory, the

execution of the Solaris Security Toolkit installs the software.

After the MD5 binaries are installed, you can use th em to verify the integrity of

executables on the system through the Solaris Fingerp rint Database. More

information on the Solaris Fingerprint Databa se is available in the Sun BluePrints

OnLine article titled The S olaris Fingerprint Database - A Security Tool for S olaris

Software and Files.

% scp md5.tar.Z msp01:/var/tmp


42/62


4. (Optional) Download and install Solaris Fingerprint Database Companion and

Solaris Fingerprint D atabase Si dekick sof tware from the S UN SOLVE ONLINE

Web site at:

http://sunsolve.sun.com

We strongly recomm end that you install these optional tools and u se them w ith the

MD5 software. These tools simplify the process of validating system binaries against

the d atabase of MD5 checksum s. Use these tools frequently to v alidate the integrity

of the Solaris OE binaries and files on the cluster n odes.

These tools are described in the The Solaris Fingerprint Database - A Security Tool for

Solaris Software and Files article.

Installing Downloaded Software and

Implementing Mod ifications

The Solaris Security Toolkit version 0.3.6 and later provides a driver

(sunfire_mf_msp-secure.driver) for autom ating the installation of security

software and Solaris OE modifications. The d river performs the following tasks:

s Installs an d executes th e FixModes software to tighten file system perm ission

s Installs the MD5 software

s Installs the Recommend ed an d Security Patch Cluster software

s Implements almost 100 Solaris OE security modifications

Note The actions p erformed by each of the scripts is described in the SunBluePrints OnLine article The Solaris Security Toolkit - Internals: Updated for Version

0.3. The hardening described is performed in standalone mode, not JumpStart

mod e, because the MSP w as bu ilt u sing an interactive Solaris OE installation. For

details on the differences between stan dalone m ode an d Jump Start mod e, refer to

the Solaris Security Toolkit documentation.

Note During th e installation and mod ifications implemented in this section, all

non-encrypted access mechanisms to the MSP such as Telnet, RSH, and FTPare

disabled. The hard ening steps do not d isable console serial access over SC serial

ports.


43/62


44/62


w To Und o a Solaris Secu rity Toolkit Run

Each Solaris Security Toolkit run creates a run directory in /var/opt/SUNWjass/

run. The nam es of these directories are based on th e date an d time the ru n is

initiated. In ad dition to d isplaying the ou tpu t to the console, the Solaris Security

Toolkit software creates a log file in th e /var/opt/SUNWjass/run directory.

Caution Do not m odify the contents of the /var/opt/SUNWjass/run directories

un der an y circumstances. Modifying the files can corrup t the contents and cause

un expected errors w hen you use Solaris Security Toolkit software features such as

undo.

The files stored in the /var/opt/SUNWjass/run directory track mod ifications

performed on the system and enable the jass-execute und o feature.

q To undo a run or series of runs, use the jass-execute -u command.

For example, on a system wh ere two sep arate Solaris Security Toolkit run s are

performed, you could un do them by using the following command and options:

Refer to the Solaris Security Toolkit docu men tation for d etails on the capabilities and

options ava ilable in the jass-execute command.

#pwd

/opt/SUNWjass

# ./jass-execute -u

Please select from one of these backups to restore to

1. September 25, 2001 at 06:28:12 (/var/opt/SUNWjass/run/

20010925062812)

2. April 10, 2002 at 19:04:36 (/var/opt/SUNWjass/run/

20020410190436)

3. Restore from all of them

Choice? 3

./jass-execute: NOTICE: Restoring to previous run

//var/opt/SUNWjass/run/20020410190436

============================================================

undo.driver: Driver started.

============================================================

[...]


45/62


Configuring the MSP SYSLOG

The MSP is configured to function as the SYSLOG repository for all SYSLOG traffic

generated by the SC. The beha vior of the SYSLOG daemon is controlled through the

file /etc/syslog.conf; in this file, selectors and actions are specified.

Each SYSLOG selector specifies the facility (for example, kern, daemon, auth, and

user) and level at which a m essage is logged. Five levels ranging from most serious

(emerg) to least serious (debug) are available. The facility groups log messages

together by su bsystem. For instance, all kernel messages are group ed togeth er

through the facility kern. Some of the facilities available include:

s kern

s daemon

s auth

s mail

s local0-7

For a complete listing ofSYSLOG facilities, refer to the syslogd(1m) man page.

Also, it is possible to substitute a wildcard (*) for the facility name in the

syslog.conf file. This approach is particularly useful w hen all messages (for

example, *.debug), or all messages at one level or higher, must be logged (for

example, *.kern).

Each SYSLOG message includ es a level. This level specifies the type of message being

generated. The m ost critical level is emerg, which is only used on messages of

particular imp ortance. Correspond ingly, the log level debug indicates that a message

contains debug ging information and may n ot be particularly imp ortant. Some of the

levels available in the syslog.conf include:

s emerg

s crit

s err

s notice

s debug

For a complete listing ofSYSLOG levels, refer to the syslogd(1m) man page.

Although you can use a w ildcard to define a facility, you cannot u se it to define a

level. Hen ce, the entry *.debug is acceptable; however, the correspond ing entry of

auth.* is incorrect and cannot be used .

In the MSP configura tion, we recommend for the secured configuration that a ll

SYSLOG messages be stored both in the /var/adm/messages file and in a sepa rate

file containing only Sun Fire Midframe SYSLOG traffic.


46/62


Note It is not recommend ed that the SYSLOG traffic be forw ard ed from t he MSP to

another SYSLOG server. If this were d one, then a SYSLOG message after beingforwarded from the MSP wou ld identify itself as having been g enerated on the MSP

and not the SC, as wou ld actually be the case.

The recommended syslog.conf should be similar to the following:

This configuration logs all incoming messages to /var/adm/messages, all SC

messages to /var/adm/sc-messages-, and displays a ll critical kernel

messages on th e console.

If an automated log parsing tool such as logcheck or swatch is used, it may be

app ropriate to generate one file containing the SYSLOG messages from the p latform

and all the dom ains. If this consolidated file is required, then add the following lines

to those listed previously:

This configuration logs all incoming SYSLOG messages to /var/adm/sc-messages

for reconciliation by an a utom ated tool.

This configuration is relatively generic and sh ould only be considered a starting

point for configuring the SYSLOG daemon on the MSP for an organization.

Note It is critical the two colum ns be sep arated b y tabs and not sp aces. If spaces

are used in an entry, the SYSLOG daem on w ill ignore that entry.

*.debug /var/adm/messages

local0.debug /var/adm/sc-messages-platform

local1.debug /var/adm/sc-messages-domain-a

local2.debug /var/adm/sc-messages-domain-b

local3.debug /var/adm/sc-messages-domain-c

local4.debug /var/adm/sc-messages-domain-d

kern.crit console

local0.debug /var/adm/sc-messages






47/62

Backing Up, Restoring, and Updating the SC 45

Backing Up , Restoring, and Updatingthe SC

This section provides information an d recommend ations for securely backing up

and restoring th e SC. In this section, the MSP is used as the dumpconfig,

restoreconfig an d flashupdate server.

Backing Up and Restoring Configurations

The dumpconfig comman d u ses the FTP protocol to save the current p latform an d

dom ain configura tions to the MSP server. The restoreconfig command uses

either the FTP or HTTP protocol to restore a p reviously saved configuration to th e

SC from the M SP server.

For comp lete descriptions and usage of the dumpconfig an d restoreconfig

commands, refer to the Sun Fire 6800/4810/4800/3800 Platform Administration Manual

and the Su n Fire 6800/4810/4800/3800 S ystem Controller Comm and R eference Manu al.

All stored platform and domain configuration information is included in the dump

file. This information includ es the MD5 hash of the p latform an d d omain

administrator passwords, the OBP password, and the SNMP community strings.

The dump file is not encrypted. Hence the MD5 hash of the platform and domain

administrator passwords and the non-encrypted OBP password and SNMP

community strings are transmitted in clear text during the dumpconfig operation.For this reason, the d um p files are saved on the MSP, thus ensu ring that th e insecure

transmission of information is restricted to the private SC network, thu s minimizing

exposure to network snooping.

When a restoreconfig operation is carried ou t, the entire saved configuration is

restored. This includes the platform administrator and domain administrator

passw ords. It is essential to ensure that the pa ssword s are known before this

operation is carried out. Refer to Con figuring Platform Adm inistrator Settings on

page 14 and Con figuring Dom ain Adm inistrator Settings on p age 25.

The Apache Web Server on the MSP is configured such th at the /msp directory is

mad e available to the SC. All backup a nd restore operations to the MSP must be

contained in this d irectory. Because the backup files created du ring a dumpconfig

are not d ifferentiated by n ame or d ate, it is important th at separate d irectories becreated for each backup for version control and tracking. The recomm end ed solution

is to create a directory for each dumpconfig using the year, month, day, and hou r.

For example: the dumpconfig performed on July 16th, 2001 at 7 p.m. would be

stored in a directory called 2001071619.


48/62


Backing Up Platform and Domain Configurations

Although the MSP is configured to resp ond to HTTP, it does not norm ally respon dto FTP because the FTP service is d isabled du ring MSP setup. To perform a

dumpconfig, the FTP service need s to be enabled on the MSP.

After saving configurations, disable the FTP service again on the MSP. The MSP is

configured su ch that a user ID and p assword are required for this operation, and the

user ID should be used only for dumpconfig an d restoreconfig operations.

w To Back Up Configurations on the MSP

1. To enable the FTP service on the MSP, log in to the MSP using Se cure She ll, then

su to root.

2. Edit the file /etc/inetd.conf, and uncomment the following FTP entry:

3. Send the inetd daemon a SIGHUP signal wi th the followi ng commands:

4. Create a directory w ith the appropriate time and date stamp on the MS P.

Before the actual dumpconfig comman d can be run , a directory on the MSP must becreated w ith the app ropriate time and d ate stamp. Based on th e example (July 16th,

2001 at 7 p.m. would be stored in a directory called 2001071619), the following

directory would be created:

5. At the SC, dump the configuration using FTP with a user name and password.

#ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -l

#ps -ef | grep inetd

root 221 1 0 Jun 08 ? 0:00 /usr/sbin/inetd -s -t

# kill -HUP 221

#mkdir /msp/2001071619

# chown msphttp:mspstaff /msp/2001071619

# chmod 770 /msp/2001071619


49/62

Backing Up, Restoring, and Updating the SC 47

Note The following example assumes a user name blueprints and password

t00lk1t on the MSP.

The command and results should be similar to the following:

6. When the dump is complete, conclude the process b y disabling the FTP entry in

the /etc/inetd.conf by commenting out the following line in the /etc/

inetd.conf:

7. Send the inetd daemon a SIGHUP signal in the follow ing manner:

8. Confirm that the FTP service is disabled by executing the following commands:

ds7-sc0:SC> dumpconfig -f ftp://blueprints:[email protected]/msp/2001071619

Created: ftp://blueprints:[email protected]/msp/2001071619/ds7-sc0.nvci

Created: ftp://blueprints:[email protected]/msp/2001071619/ds7-sc0.tod

ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -l

# ps -ef | grep inetd

root 221 1 0 Jun 08 ? 0:00 /usr/sbin/inetd -s -t

# kill -HUP 221

# ftp localhostftp: connect: Connection refused

ftp> quit


50/62


51/62


52/62


4. Unpack the files containing the patch and place them in a subdirectory under the

Apache Web S erver document root d irectory /msp as follows:

5. Follow the instructions in the Install.info file.

In our example, sc-app, SB0, SB2, IB7, and IB9 are to be updated from version

5.11.6 to 5.11.7. The RTOS will be u pd ated from re lease 17 to 17B. No t all sy stem

boards are powered up , so the all option cannot be used.

# cd /msp

# unzip 111346-02.zip

Archive: 111346-02.zip

creating: 111346-02/

inflating: 111346-02/Install.info

inflating: 111346-02/VERSION.INFO

inflating: 111346-02/copyright

inflating: 111346-02/sgcpu.flash

inflating: 111346-02/sgpci.flash

inflating: 111346-02/sgrtos.flash

inflating: 111346-02/sgsc.flash

inflating: 111346-02/README.111346-02


53/62


54/62

52 Securing the Sun Fire Midframe

Documents

Sun System Controller