Security

The interface to DOE Cyber Securiry and security contact for STAR is the Software & Computing leader.

The role of the security contact is to participate in the design and elaboration (writing) of the BNL Cyber Security program plan (CSPP) and define a STAR specific security layer consistent with BNL CSPP and DOE CS directives.

People helping with this process are:

  • Wayne Betts

Under this tree, you will find security related documents and information (plans, draft policies, etc..).

You will need to subscribe to the Software and Computing organic group to be able to view most of those documents.

 

 

2006 documents

This page is being built.

At the bottom of this page, we have several documents written in 2006 as part of the Cyber-Security effort to describe sub-systems in the research enclave. An enclave is defined by its level of security, controls and accessibility. A sub-system is defined as a sub-division of an enclave and may be a "sub-enclave". Each eclave requires documentation and a clear description of how the components interact with each other, including the human component (physical access).

  • STAR-OperationalNeed-Policy_XP
    Date: 10/24/2006
    Contributors: Jerome Lauret (lead), Wayne Betts, Valeri Fine
    Items in darker orange are addiitonal changes we would request. Please note that the screen-locking requirements are not part of the Windows policiy but one of the purpose of the SDAS enclave document. The main Physics department CS document has the auto-locked screen exemption specified as operational need for online enclaves.
  • STAR-General-WorkstationsPolicy_XP
    Date: 10/24/2006
    Contributors: Jerome Lauret & Wayne Betts (leads), Valeri Fine
    This is a spreadsheet like document displaying Windows XP base line policy and set values. The last comment are generic comments which may apply to the "general Workstation"policy or notes for future policy. Color coding includes:
    • red/orange: we have a concern with this item and will ask for alteration if allowed and consistent with BNL CS plan. We consider the BNL setting a reduction of our security posture (not an enhancement)
    • yellow: general discussed item, refer to comment
    • green: we recommend this item as additional setting in the policy
  • SDAS-Complete
    Date: From 7/19/2006
    Contributors: Jerome Lauret (lead), Wayne Betts, Jeffery Landgraf, Michael DePhillips, Jon Engelage and Mike Cherney
    This document is a "live" document and will evolve as time goes. Versions below.
    • SDAS-Complete-v0.7 was submitted for DOE Cyber Security review of our CSPP on July 19th 2006.
      Date: 7/19/2006
      Contributors: Jerome Lauret (lead), Wayne Betts, Jeffery Landgraf, Michael DePhillips, Jon Engelage and Mike Cherney
  • SDAS-enclave-v3
    Date: 7/17/2006
    Contributors: Jerome Lauret (lead), Wayne Betts, Jeffery Landgraf with feedback from Jon Engelage
    This document describes the STAR online system. This document was the preliminary work to the BNL CSPP. Further document are displayed and inventoried in a separate enumeration.

2007 documents

Current documents

The document listing is as follow:
  • Online Computers variance
    Purpose: The purpose of this variance document is described in the background section of this document. To achieve a complete security package, at least one variance has to be provided. This process is indivisible of a an enclave document. An enclave may however relate to several variance document.
    Submitted: 2007/02/15
    Re-submitted: 2007/03/30
    Contributors: Jerome Lauret
    Feedback: Re-submission added feedback from CS team. Main additions to initial document: need for better explaination of keyboard lock, explain local account, explain physical access security, explain mode of updates
    Status: Pending
  • Physical Access Problem statement & Proposal
    Date: 2007/01/12
    Contributors: Jerome Lauret (lead), Wayne Betts after a visit to the DAQ, CR, WAH, Gas rooms and review of access control.
  • Variance-Form-v0.4-STAR-GeneralDesktop
    Submitted: 2006/11/07
    Contributors: Jerome Lauret
    Feedback: None
    Status: Rejected 2006/12/19 by Samuel Aronson, Laboratory Director. "Explaination" below.
    The requested exemption from Remote Registry services defeats the ability to manage 
    STAR Windows systems remotely. Exemptions require there to be an operational need. 
    I see only a statement that more access = higher risk. While I agree that's so, in 
    the interest of managing the cyber security of the whole laboratory, I will consider 
    variances only for systems that will not operate properly if subjected to remote 
    configuration management.  Given that, I am not approving the request.
    
    Sam
    
    Follow-ups: We offered to kindly demonstrate the Remote Registry service vulnerability to Peter Bond (2006/11/30), Tom Schlagel (2006/12/01), Andrew Ferguson (2007/01/02) and J.D. Fluckiger (2007/01/09) and have been consistently turned down as attempting a demo. Sam Aronson informed of the risk on 2006/12/19.
  • Proposed Windows Policy based (commented) modifications.
    1. STAR Operational Need Policy XP
      STAR-OperationalNeed-Policy_XP-20070111.pdf
      Date: 2007/01/11
      Contributors: Jerome Lauret, Wayne Betts, Valeri Fine, Jeff Landgraf
      STAR-OperationalNeed-Policy_XP
      Date: 2006/10/24
      Contributors: Jerome Lauret (lead), Wayne Betts, Valeri Fine
    2. STAR-General-WorkstationsPolicy_XP
      Date: 2006/10/24
      Contributors: Jerome Lauret & Wayne Betts (leads), Valeri Fine
    Color code includes
    • red/orange: we have a concern with this item and will ask for alteration if allowed and consistent with BNL CS plan. We consider the BNL setting a reduction of our security posture (not an enhancement)
    • yellow: general discussed item, refer to comment
    • green: we recommend this item as additional setting in the policy
  • SDAS-v0.8
    This document was created from tghe 2006/07/19 document (Contributors: Jerome Lauret (lead), Wayne Betts, Jeffery Landgraf, Michael DePhillips, Jon Engelage and Mike Cherney) submitted to DOE CyberSecurity. The document went through one more reshape (comments and additional questions) and accepted on 2006/10/13 . STAR management board inform of documen acceptance on 2006/10/17, author on 2006/10/27 (during You do not have access to view this node)

    Note that physical access is described in the SDAS document and core part of "the plan". We suggested (at STAR's managerment meetings) that a PASS card control system, card sweeper locks or combination locks should be installed to ensure further physical access requirement and pro-actively prepare for the question of "how do we control access". This was requested on 2006/12/19, 2006/12/11, 2006/11/28, 2006/10/24, 2006/10/17, 2006/10/02, 2006/09/05, 2006/08/29. Further reminders were made on 2007/03/13, 2007/02/27, 2007/01/23, 2007/01/09. The scope of physical access is VERY broad (could come for ANY of the components we have, from network to nodes to hardware). It was mentionned consistently time that it is my VERY strong beleif that we WILLL be challenged on our model for physical access control (especially during shift). Only a question of time. I suggested a strict revision of shift-crew responsibilities (and challenge anyone who is not known). An online Physical Accessdocument and statement was sent 2007/02/27, 2007/01/13, 2007/01/10 (statement only) upon inaction on this items, spaning from as early as August 2006 to March 2007.


 

Document creator's note ...

 

Irgendwann fällt jede Mauer
Irgendwann fällt jede Mauer
Eventually every wall falls

 

... but at what price?

 

Background

Please consult 2006 documents for past document and information left for historical purposes. However, the documents herein ar ethe most up-to-date and should be referred to as startup.

As before, the bottom of this page displays several Cyber-Security documents we provided to DOE and the BNL/ITD describing our sub-systems in the research enclave. An enclave is defined by its level of security, controls and accessibility. A sub-system is defined as a sub-division of an enclave and may be a "sub-enclave". Each eclave requires documentation and a clear description of how the components interact with each other, including the human component (physical access).

The role of an variance document is to describe how and why a set of computer within an enclave need to diverge (as per its baseline settup) from the BNL base policies. Some wording in a variance document may be a repeat of the information related to the enclave itself. The wording MUST remain consistent however. As an example, an exemption of the screen saver requirement may be described in the enclave document but would benefit from being described in each variance document.

An enclave document is a live document and should be revised as necessary in conjunction of one or more variance document. Changes may be justified by:

  • the need to reshape our security model based on a change of architecture, software layout, component interaction
  • a change in the BNL baseline policies requiring additional items in our variance document
  • a reshape of the network
  • ...
... and so on. Revision could be made due to internal or external to STAR (DOE/CS level) modification of the Cyber Security plan.

 

 

Othe readings

Before you read the documents below, you may consult the following pages and references for a bakcground philosphy of what we are trying to achieve.
  1. Extracted topics
  2. The Run VII preparation page (and notes from referenced meetings wherever available and especially meetings #3, #5, #7, #8)
  3. You do not have access to view this node slide 14 to 17
  4. You do not have access to view this node slides 24 to 27
  5. Online and Offline Computing (STAR Critique) slides 10 to 13
In short, we are trying to understand DOE requriments (sometimes changing) and map those requirement to tangible realities (technical solutions) we can (a) describe i.e. document and (b) implement (deploy).

 

2008 documents

This page will have security related documents and policy previews.

The current list is:

 

 

Domain scanning

General

Domain scanning page shows when the STAR domain were last scanned. Quarterly scans are mandated by BNL CSPP. In red, ongoing scans or lines needing update based on results.

Domain Purpose Last Scanned Next due
6 {nothing left on this network but shows in scheduled scans} 2016-06-29 N/A
16 shows in group=star but only a few nodes there
tcarmada, SteveV and a few dhcp nodes, ...)
Mostly rhic - do we move things out of this?
2015-06-29 N/A
54 {was dbXX exported - we should have nothing else there} 2015-05-12 N/A
59 Offline services (fc, orion, some user nodes, etc ...)
Range shared w PHENIX/RCF 130.199.59.192+ is STAR
2015-06-29 N/A
60 starp - range 1 2015-04-08  
61 starp - range 2 2015-04-08  
162 STAR visitor network (trailer) dean, startpc, ...
Possibly dh*.s162
2015-04-08  
216 daqst1, padrazo, presley,
etc ... user nodes.
This network is shared with Physics
2015-06-29  

 

Screen snapshot

Attached below is a screen snapshot of the ITD interface to the quarterly scan. In case of un-schedule scan, refer to the below to see what WE scheduled and the latest state snaphot.

SNAPSHOT BELOW IS NOT UP-TO-DATE

List of STAR Conduits

List of conduits

  • Grayed items are historical records

  • Italic are incomplete or submitted renewal requests

  • Bold may be indicating attention is required

Server

IP

Port

Kind

Requested

Expiration

Conduit
direction

Justification

STARGRID01.RCF.BNL.GOV
STARGRID02.RCF.BNL.GOV
STARGRID03.RCF.BNL.GOV STARGRID04.RCF.BNL.GOV

130.199.180.111
130.199.180.112
130.199.180.113 130.199.180.114

20000-30000

Extension

Owners: John Hoover / Wayne Betts
stargrid02: Jerome Lauret

2009/05/20
2004/10/12
2004/10/12 2004/10/12

2015/06/11
2015/10/07
2015/06/11
2015/03/20

 

This conduit is for the STAR RHIC users, in particular, those collaborators that are using Grid software.
This is a Grid server for STAR with the standard Globus software installed on it, either packaged by VDT directly or repackaged by the OSG (Open Science Grid). The port range (20000-30000/tcp in this case) is used by the gatekeeper's batch
job-manager processes to allow the user to query and get output fromtheir jobs. It can also be used by the GridFtp server when doing
parallel stream file transfers to open up multiple data channels. If theconduit were denied, then the user's software that requires this service would not function and they most likely would not be able to do their work effectively or at all.

STARGRID01.RCF.BNL.GOV
STARGRID02.RCF.BNL.GOV
STARGRID03.RCF.BNL.GOV

STARGRID04.RCF.BNL.GOV

130.199.180.111
130.199.180.112
130.199.180.113

130.199.180.114

2811

Extension

Owners: John Hoover / Wayne Betts
stargrid02,03: Jerome Lauret

2005/02/14
2003/05/12

2003/05/12 2004/05/20

2015/06/11
2015/10/07
2015/06/11
2015/03/20

 

This conduit is for the Star RHIC users, in particular, those collaborators that are using Grid software. This is a Grid server for STAR with the standard Globus software installed on it, either packaged by VDT directly or repackaged by the OSG (Open Science Grid). Port 2811/tcp is used by the globus GridFtp server for GSI authenticated file transfers. If the conduit were denied, then the user's software that requires this service would not function and they most likely would not be able to do their work effectively or at all.

STARGRID01.RCF.BNL.GOV
STARGRID02.RCF.BNL.GOV

STARGRID03.RCF.BNL.GOV
STARGRID04.RCF.BNL.GOV

130.199.180.111
130.199.180.112

130.199.180.113
130.199.180.114

2135

Extension

Owners: John Hoover / Wayne Betts
stargrid02: Jerome Lauret

2005/02/14
2003/05/12

2003/05/12
2004/05/20

2015/06/11
2015/10/07
2015/06/11 2015/03/20

 

This conduit is for the STAR RHIC users, in particular, thosecollaborators that are using Grid software. This is a Grid server for STAR with the standard Globus software installed on it, either packaged by VDT directly or repackaged by the OSG (Open Science Grid). Port 2135/tcp is used by the globus information provider (ldap based service) which makes information about the local site & services available to users. If the conduit were denied, then the user's software that requires this service would not function and they most likely would not be able to do their work effectively or at all.

STARGRID01.RCF.BNL.GOV
STARGRID02.RCF.BNL.GOV
STARGRID03.RCF.BNL.GOV
STARGRID04.RCF.BNL.GOV

130.199.180.111
130.199.180.112

130.199.180.113
130.199.180.114

2119

Extension

Owners: John Hoover / Wayne Betts
stargrid02: Jerome Lauret

2005/02/14
2003/05/12
2003/05/12
2004/05/20

2015/06/11
2015/10/07
2015/06/11
2015/03/20

 

This conduit is for the STAR RHIC users, in particular, those collaborators that are using Grid software. This is a Grid server for STAR with the standard Globus software installed on it, either packaged by VDT directly or repackaged by the OSG (Open Science Grid). Port 2119/tcp is used by the globus gatekeeper, which accepts user batch jobs for processing on a cluster. If the conduit were denied, then the user's software that requires this service would not function and they most likely would not be able to do their work effectively or at all.

STARGRID02.RCF.BNL.GOV

130.199.180.112

9443

Extension

Owners: Jerome Lauret / Wayne Betts

2008/07/10

2015/10/07
Is this still needed?

 

This is for WS-GRAM job submissions to the STAR-BNL OSG gatekeeper, which was specifically requested by LIGO. Denial of this conduit would prevent STAR from participating fully in OSG.

STARGRID02.RCF.BNL.GOV

130.199.6.168

6001-6003

 to {192.91.245.5, 192.91.244.18, 131.215.207.61, 131.215.207.35, 131.215.145.190}

Obsolete

Owners: Jay Packard / John Hover

2008/01/17

2009/01/17
Conduit dropped at GK upgrade in 2009

 

The conduit's purpose is to provide computer status and usage
information within a resource discovery and monitoring system called MonALISA, as used by the Open Science Grid (OSG). The OSG is a DOE-supported grid computing framework, in which STAR is a contributor, as well as a beneficiary. Without this service functioning (as would be the case without this conduit), the ability of STAR to contribute (and benefit) from OSG efforts would be greatly hampered, since we would not be using one of the primary tools at the heart of the OSG framework.
The ability of STAR collaborators to monitor our own activities would be
diminished, and the OSG community's perception of STAR's level of commitment would be reduced.

ONLDB.STARP.BNL.GOV 130.199.60.70 3316
New
 
Owners: Jerome Lauret / Wayne Betts
20123/04/16 2015/04/18 i
ANY(internal)
The MySQL database server is running on this machine and port. The service supports STAR operations (data production, file management) and is essential to smooth operations. Any users at BNL (internal or wireless) should be able to access the information from the database service running there. Access from outside BNL is not required.

ONLDB.STARP.BNL.GOV
ONLDB2.STARP.BNL.GOV
ONL10.STARP.BNL.GOV
ONL11.STARP.BNL.GOV

130.199.60.70
130.199.60.89
130.199.60.101
130.199.60.102

3501-3503

Extension

Owners: Jerome Lauret / Wayne Betts

2007/01/20
2009/12/02
2010/04/05
2010/04/05

2015/04/18
2015/03/20
2015/06/11
2015/06/11

 

MySQL port opening for reading ShiftLog information from remote. Using an OS portable and stand-alone GUI, STAR users will be able to view events and display the content of our electronic ShiftLog. Write access may also be granted and controlled at MySQL access grant level. Necessary for remote sub-system expert support, the impact of having this conduit denied would be that we would not be able to leverage remote expertise and would lose information.

MySQL port opening for reading Shift related information for our local domains. Several nodes are provided for internal load balancing purposes.

Port range was created in 2010 only (consistency lacked prior).
3501 RunLog, 3502 Conditions, 3503 DAQ. Only Runlog needs world access.

DBBAK.STARP.BNL.GOV 130.199.60.88 3400-3417
New
 
Owners: Jerome Lauret / Wayne Betts
2012/11/19 2014/08/11 i
ANY(internal)
The port range is used to access historicla data on past runs and essentially, our ShiftLog information. If not provided, support for past RHIC data would be jeopardized. However, only internal access is needed.
ONL11.STARP.BNL.GOV 130.199.60.102 5672

Re-created

Owners
: Jerome Lauret / Wayne Betts

2010/11/03
2011/12/28
2011/11/15
Was pending

This conduit was not created??

No longer in the list of conduits (no explaination) and no complaints came

 

This conduit is required to get monitoring information from the new Online AMQP-based data collection system, a system which will gradually replace our current EPICS based system. Without this conduit, we would not be able to run this system and hence, not able to monitor the experiment's environmental conditions.

MONGODEV.STARP.BNL.GOV 130.199.60.168 80
443

Created

Owners
: Jerome Lauret / Wayne Betts

2012/09/13 2014/10/04
i
ANY(internal)
Web service would be used to deploy a new message collector allowing us to trace/track our job workflows (online data collection, offline data reconstruction). We will rely on a Webservice approach for this logger. Not having this conduit would not allow STAR to push forward the next technology frontier. Conduit is ONLY needed INTERNALly to BNL (no access from the outside world required at this time / BNL Wireless could be excluded).

HESTON.STAR.BNL.GOV

130.199.88.128

3336

Obsolete

2008/01/17

2009/01/17
Closed
2010/03/16

 

As duvall i.e. as request 2679, this node need port 3336 to be exported to remote site for FileCatalog access at remote site. MySQL protections will allow outbound-in read-only access however. This node and the next request (heston) are part of a two db-slave layout. If the conduit were denied BNL would not be able to provide the FileCatalog service to other sites. If the conduit were denied BNL would not be able to provide the FileCatalog service to other sites not benefiting from a private local copy.

DB05.STAR.BNL.GOV

130.199.88.63

3316

Extension

Owners: Jerome Lauret / Wayne Betts

2008/08/15

2010/08/20
Expired, not exported + node moved to .54

 

We request port 3316 to be opened and by then, adding one more database server for export. This server is used for exporting (read-only) calibration constant database information to our Tier 1 and Tier 2 users as necessary. It is part of a a bundle of secondary server export to the outside world.

DB06.STAR.BNL.GOV

130.199.59.206

3316

Extension

Owners: Jerome Lauret / Wayne Betts

2008/01/19

2015/03/20

i
ANY

This is an alternate read-only server for the STAR experiment's run conditions database for use by the BNL data production. 3316  is a nonstandard MySQL port.

DB06.STAR.BNL.GOV

130.199.88.67

3316

Obsolete

2006/11/02

2008/11/21

 

We request port 3316 to be opened and by then, adding one more database server for export. This server is used for exporting (read-only) calibration constant database information to our Tier 1 and Tier 2 users as necessary. It is part of a a bundle of secondary server export to the outside world.

DB07.STAR.BNL.GOV

130.199.59.207

3316

Extension

Owners: Jerome Lauret / Wayne Betts

2008/01/17

2015/03/20

i
ANY

We request port 3316 to be opened and by then, adding one more database server for export. This server is used for exporting (read-only) calibration constant database information to our Tier 1 and Tier 2 users as necessary. It is part of a a bundle of secondary server export to the outside world.

DB08.STAR.BNL.GOV

130.199.88.43

3316

Extension

2006/10/10

2008/11/28
Closed 2008/12/09

 

INBOUND ONLY - This is an alternate read-only server for the STAR experiment's run conditions database for use by the BNL data production. 3316 is a nonstandard MySQL port.

DB08.STAR.BNL.GOV

130.199.59.208

3316

Extension

Owners: Jerome Lauret / Wayne Betts

2008/12/15
2011/02/04
2012/03/02

2011/01/04
2012/02/04
2015/03/20

i
ANY(internet)

INBOUND ONLY - This is an alternate read-only server for the STAR experiment's run conditions database for use by the BNL data production. 3316 is a nonstandard MySQL port. The server is used for exporting (read-only) calibration constant database information to our Tier 1 andTier 2 users as necessary.

FC1.STAR.BNL.GOV

130.199.59.221

3336

New

Owners: Jerome Lauret / Wayne Betts

2009/09/25
2011/02/23

2010/09/25
2015/03/20

i
ANY(internet)

This node need port 3336 to be exported to remote site for FileCatalog access at remote site. This node is part of a multi-master db-slave layout. If the conduit were denied BNL would not be able to provide the integrated FileCatalog service to other sites.

ORION.STAR.BNL.GOV

130.199.59.198

443

Extension

Owners: Jerome Lauret / Wayne Betts

2007/01/04

2013/10/17

 

THIS IS A REPLACEMENT WEB SERVER FOR CONNERY. Public web server used to coordinate STAR collaboration provide public and private web access to our collaborators in support of the Physics Program (Physics Working group documents, mailing lists access via web, STAR collaboration web server). If the conduit were removed we would not be able to perform our science nor disseminate our findings and excitement of our field (as required by DOE).

ORION.STAR.BNL.GOV

130.199.59.198

80

Extension

Owners: Jerome Lauret / Wayne Betts

2007/01/04

2013/10/17

 

(same as above)

DUVALL.STAR.BNL.GOV

130.199.88.125

3316

Obsolete

2006/02/10

2003/05/12

 

The STAR MySQL database server is running on this machine and port. Any STAR collaborator running STAR event reconstruction will need access to this data-server regardless of where their process is executing. This could be on a number of machines at any of the 45 STAR institutions.

DUVALL.STAR.BNL.GOV

130.199.59.233

3316

Extension

Owners: Jerome Lauret / Wayne Betts

2003/05/12

2013/03/26

i
ANY(INTRANET)

The MySQL database server is running on this machine and port. The service supports STAR operations (data production, file management) and is essential to smooth operations. Any users at BNL (internal or wireless) should be able to access the information from the database service running there. Access from outside BNL is not required.

CH2LINUX.STAR.BNL.GOV

130.199.162.131

80

Obsolete

N/A

2008/09/05
Closed 2008/09/19

 

This online STAR web server is the primary source of information for worldwide collaborators to check on the current and past status of the STAR detector and data acquisition in operation. Without sharing this information, STAR collaborators would be unable to effectively participate in the experiment and their ability to do physics analysis would be negatively impacted.

Note: All operational functions should be provided from dean.star.bnl.gov aka online.star.bnl.gov

CH2LINUX.STAR.BNL.GOV

130.199.162.131

8080

Obsolete

2006/08/23

2007/08/24
Closed / upgrade

 

This online STAR web server is the primary source of information for worldwide collaborators to check on the current and past status of the STAR detector and data acquisition in operation. Without sharing this information, STAR collaborators would be unable to effectively participate in the experiment and their ability to do physics analysis would be negatively impacted.

DEAN.STAR.BNL.GOV

130.199.162.136

80

Extension

Owners: Jerome Lauret / Wayne Betts

2007/02/23

2015/03/20

Reverse Proxy
2012/04/11 for www alias.This should no longer be needed

[Confirmed]

 ANY

This server will be a replacement for ch2linux This conduit is for the
STAR experiment, within the physics department. This web server is the
primary source of information for worldwide collaborators to check on
the current (including dynamic near-real time content) and past status of the STAR detector and data acquisition in operation. Without some method of sharing this information with the world, STAR collaborators from institutions around the world would be unable to effectively participate in the experiment -- they would be unable to sign-up for experiment shifts or to monitor the ongoing activities and even their ability to do physics analysis would be negatively impacted.

DEAN.STAR.BNL.GOV

130.199.162.136

443

Extension

Owners:

Jerome Lauret / Wayne Betts

2007/02/23

2015/03/20

Reverse Proxy
2012/04/11

for the www alias.
This sould no longer be needed


[Confirmed]

 ANY

(same as above)

DEAN.STAR.BNL.GOV

130.199.162.136

8649

Extension

Owners:

Jerome Lauret / Wayne Betts

2009/02/20

2015/03/20

o
ANY(internal)

dean, our online Web server, needs to be able to access ANY of the .60 nodes for communicating with Ganglia monitoring. dean is the communicator and need access to the .60 8649 port. Not having this
conduit will make either the scalability of our Ganglia monitoring doubtful or prevent monitoring from the two domains. There are NO NEEDS to have this port opened to something else than for .60 to the .162 communication (and only dean needs to be able to communicate with this
port).

ROBINSON.STAR.BNL.GOV

130.199.59.230

3336

Extension

Owners: Jerome Lauret / Wayne Betts

2009/07/23
2008/01/23

2013/09/28
2010/09/04

128.55.36.0
255.255.255.0

[IN-BOUND 128.55.36.0 255.255.255.0]
This conduit is required to allow database synchronization between STAR database servers at NERSC and BNL.

Note:  Confirmed D.A. 2013/05/07 this conduit is no longer needed.

[INBOUND 128.55.24.46]
File Catalog data is being replicated via MYSQL Master/Slave Replication on a single port to NERSC. The M/S replication additionally provides an offsite, redundant backup for the file catalog replication. The absence of this conduit would have a medium impact: distributed computing and awareness of file replica is essential to scheduling optimization and data transfer which would cease.

ROBINSON.STAR.BNL.GOV

130.199.59.230

3306

Extension

Owners: Jerome Lauret / Wayne Betts

2012/11/02
2003/05/12

2014/08/11
2012/10/18

i
ANY(internal)

Provides a public database access needed to co-ordinate STAR detector work INBOUND ONLY access only - provides a public database access needed to co-ordinate STAR detector work. Without this conduit, local data mining cannot be executed.

CONNERY.STAR.BNL.GOV

130.199.89.5

80

Extension

2006/09/15

2007/03/18

 

public web server used to coordinate STAR collaboration provide public and private web access to our collaborators in support of the Physics Program (Physics Working group documents, mailing lists access via web, STAR collaboration web server). If the conduit were removed we would not be able to perform our science nor disseminate our findings and excitement of our field (as required by DOE).

Note: Server replaced by orion.star.bnl.gov along an OS upgrade.

CONNERY.STAR.BNL.GOV

130.199.89.5

8080

Extension

2006/09/15

2007/03/18

 

public web server used to coordinate STAR collaboration provide public and private web access to our collaborators in support of the Physics Program (Physics Working group documents, mailing lists access via web, STAR collaboration web server). If the conduit were removed we would not be able to perform our science nor disseminate our findings and excitement of our field (as required by DOE).

Note: Server replaced by orion.star.bnl.gov along an OS upgrade.

ALTERA.STAR.BNL.GOV

130.199.88.15

47

Extension

2007/03/16

 

 

This conduit will use protocol 47 (Generic Routing Encapsulation) to share licensed software for collaboration work within the Atlas Experiment between the indicated CERN machine and the BNL machine. Software license are currently in use for the STAR experiment as well, hence the ownership of the conduit.

Note: Conduit was not renewed, service no longer needed.

AUTEUIL.STARP.BNL.GOV

130.199.60.137

to port 7778
on Avamar1

New

Owners: Jerome Lauret / Wayne Betts

2013/08/01

2014/08/12

 
Possibly this was left expired ...
TBC

This conduit is for auteuil to contact the Avamar server (130.199.76.196) on port 7778 to run the Avamar administrator console (to perform restore  operations).

DASHBOARD1.STAR.BNL.GOV

130.199.162.181

80
443

New

Owners: Jerome Lauret / Wayne Betts

2014/09/23

 

 
First request
TBC

i
ANY(EXTERNAL)

This secondary Web server for our online enclave will host a WebSocket based service in order to provide low-latency updates to real-time monitoring plots to remote participants. Normal HTTP cannot provide the feature we seek to support > 1000 channel updates / seconds. WebSocket is a typical solution for scalable high throughput updates requirements. A transparent reverse proxy setup (via Squid) does not support WebSocket hence the conduit is needed for providing remote collaborators with real-time graphical representation of the detector monitoring. All content of this Web server will be access protected (there will be no public information).

Without this conduit, STAR would be an impasse and not able to pursue the deployment of its scalable architecture aimed at providing full support for detector upgrade and increase data demands.

 

MegaRAID Storage Manager used on STAR servers


Notes about the use of MegaRAID Storage Manager (MSM) with STAR servers.  This page was initially created August 10, 2022 with hastily prepared notes, with more details and cleanup expected to come. 

Versions of MSM for many years included Java JREs with log4j software versions that were unsupported and flagged by the Nessus scans.  Somewhere between MSM 17.05.02 and MSM 17.05.06-00, Java was dropped from the MSM bundle.  However, MSM still uses Java, so Java must be installed separately, and configuration is necessary for MSM to know what Java to use.

For RHE/Sc Linux 7.x, the Java needs can be met by installing java-1.8.0-openjdk and java-1.8.0-openjdk-headless (though there are other alternatives for supported java installations) and creating /etc/profile.d/MSM-Java.sh with the following content (assuming the use of "stock" java packages from RHE/Sc Linux 7 repos that update /etc/alternatives/java):
JRE_HOME='/etc/alternatives/jre'
export JRE_HOME
(by using /etc/alternatives/java, I *hope* that updates to the java package will not require any manual intervention...  TBC!  - of course, one can instead use a direct full path for JRE_HOME, such as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-1.el7_9.x86_64/jre/bin/java , but keep in mind it may require manual ongoing maintenance with java updates and restarting of MSM components)

Update in October 2023:  RHE/ScLinux 7.x and RHE/Sc/Alma Linux 8.x also has java-11-openjdk (and java-11-openjdk-headless), though I have not tested MSM with java-11 on 7.x.  For RHE/Sc/Alma Linux 8.x, there is also java-17-openjdk (and java-17-openjdk-headless), but my tests with MSM using java-11 and java17 on RHEL 8.8 were NOT successful - though the vivaldiframeworkd starts, and the user GUI starts, MSM email alerts were broken.  I did not take much time trying to troubleshoot this.  In short, at this time, I'm sticking with java-1.8.0.

We typically install MSM with the "local" option ("install.csh -l"), though there are other options that were selected at installation in some instances, so the startup may not be the same in all cases.  (IMO, there's very little value in inter-machine communication for RAID monitoring.)

The default MSM alert configuration should be adjusted for new installations.  The main items are to set email recipient(s) and SMTP parameters, and to enable emails for critical events.  Additionally, the default settings may produce some extraneous emails that can be disabled per event (and may vary machine-by-machine).  A common .xml file can be used with only a little bit of per-machine customization for the <nic> and hostname in the <sender>.  (Actually, there is one additional detail for the <servername> depending on the server's location on the network - either adminmail.rcf.bnl.gov or bnl.gov should be used as the mail relay host (<servername>).  Unfortunately, upgrading MSM seems to lose the existing alert configuration - one can usually save it before upgrading and re-import it after the upgrade.

As of August 18, 2022, the latest MSM software I could find was available here: https://docs.broadcom.com/docs/17.05.06.00_MSM_Linux-x64.zip




Server MSM Software version
db01.star  17.05.06-00
db02.star   17.05.06-00
db04.star  17.05.06-00
db06.star  17.05.06-00
db07.star  17.05.06-00
db08.star  17.05.06-00
duvall.star  none, but it appears to have MegaRAID controller (TBD)
fc1.star  17.05.06-00
fc2.star  17.05.06-00
fc3.star  17.05.06-00
fc4.star  17.05.06-00
heston.star  17.05.06-00
robinson  17.05.06-00
stcn01.star  17.05.06-00
stcn02.star  17.05.06-00
   
   
stcn03.star  17.05.00-02
stcn04.star  17.05.00-02
   
cephmon02  17.05.06-00
onldb2  17.05.06-00
onldb4-new.starp?  17.05.06-00?
stargw1.starp  17.05.06-00
stargw4.starp  17.05.06-00
stargw5.starp  17.05.06-00
sun  
sunbelt  17.05.00-02
   
 lots more...?  
   
   


Nessus false positives and errors

Here are the list of Nessus scan results that are marked as False Positives, Operational Need, Acceptable Risk, etc. 
Listings in italics have disappeared from Nessus results (reason not always known) since marked.  

Reasons for "date nessus result found gone" are as follows:

  • The CS database is keyed on (1) machine IP (2) MAC (3) nessus ID (the test # from nessus)  (plus (4) the port)
  • While the nessus ID should not change often nor should the IP, any change in those first three information would make the reason disappear

 The only path is to document the explanations.
 

Nessus findings on STAR DB servers with False Positive (list started March 11, 2008)
NODE RISK PORT Nessus Plugin ID ISSUE DATE ADDED COMMENT IN NESSUS DATABASE

DATE NESSUS 

RESULT FOUND GONE

onldb2.starp.bnl.gov HIGH 3601   Synopis: The remote database server can be accessed without a password.

(anonymous account does not have a password)
2013/03/20 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  
dbbak.starp.bnl.gov HIGH 3400-3413  

Synopsis : The remote database server can be accessed without a password.

Plugin output : The anonymous account does not have a password.

06/11/2012

3404: 12/16/2013
Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  2012/11/19
fc3.star.bnl.gov  HIGH  3316     anonymous account w/o password  03/29/2011  Operational need:  "Access without a password is limited to read-only by configuration. No sensitive information is available in this database."
 
6/11/2012
db01.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db02.star.bnl.gov  HIGH 3316   anonymous account w/o password 3/12/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db04.star.bnl.gov HIGH 3400-3412
3316
  anonymous account w/o password 3/31/2014 Operational Need:  Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db05.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db06.star.bnl.gov  HIGH 3316   anonymous account w/o password 02/12/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db08.star.bnl.gov  HIGH 3316   anonymous account w/o password 02/12/2014
found again (and retoggled) on 10/24/2014
Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db07.star.bnl.gov  HIGH 3316   anonymous account w/o password 02/12/2014 Anonymous/passwordless access is read-only by configuration and by design. No sensitive information is available through this access.  
db10.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db11.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db12.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db13.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db14.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db15.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db16.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db17.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
db18.star.bnl.gov  HIGH 3316   anonymous account w/o password 2/26/2014 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
mq01.starp.bnl.gov  HIGH 3606   anonymous account w/o password 1/9/2015 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
mq01.starp.bnl.gov
mq02.starp.bnl.gov
openstack1.starp.bnl.gov
MEDIUM 5672/tcp 87733 AMQP cleartext authentication 5/18/2016

openstack1 added on 9/28/2016
This is by intent and we accept the associated risk which we consider to be very small.  
mongodev01.starp.bnl.gov
mongodev02.starp.bnl.gov
mongodev03.starp.bnl.gov
 
MEDIUM 27017/tcp 81777 MongoDB Service access without authentication 9/29/2016 The access to publicly available information is expected. There is no real privileged access allowed on this service/server.  
heston.star.bnl.gov  HIGH 3316   anonymous account w/o password 5/13/2013 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
fc3.star.bnl.gov  HIGH 3316   anonymous account w/o password 5/13/2013 Anonymous/passwordless access is read-only by configuration. No sensitive information is available through this access.  
dean.star.bnl.gov (BNL and external repos) MEDIUM 80/tcp, 443/tcp  40984 browseable directories 4/19/2016 This is the desired behaviour for this server.  It is not exposing any sensitive information.  
bcf-console.star.bnl.gov MEDIUM 443   Encrypts traffic using TLS / SSL but allows a client to insecurely renegotiate the connection ? This device has no configuration options to disable renegotiation. It also has the latest (and likely last) firmware and software updates from the vendor, so it is unlikely to ever be correctable.  
bcf-console.star.bnl.gov MEDIUM 443   MITM/POODLE 12/1/2014 Vendor support for this unit ended before POODLE was known, and the unit is not configurable to disable SSLv3 or to use TLS Fallback SCSV. It is rarely accessed (by only 2-3 people), and will only be accessed by internal clients that do disable SSLv3, which is believed to prevent the MITM nature of the attack.  
bcf-console.star.bnl.gov MEDIUM 443 42873 SSL Medium strength ciphers 11/27/2018 This unit has no configuration option to disable these ciphers.  
bcf-console.star.bnl.gov HIGH 443 20007 SSLv3 supported 11/27/2018 This unit has no configuration to disable SSLv3.  
epson7520.star.bnl.gov MEDIUM 161/udp 41028 default SNMP community string 12/02/2015 This device does not allow changes to the SNMP public community string.  
epson7520.star.bnl.gov MEDIUM 445/tcp 57608 signing not required on SMB server 12/29/2016 (missing & re-added on 9/26/2017) This printer has no configuration options to alter the SMB server behaviour.  The risk is acceptable.
 
splat-s60.starp.bnl.gov MEDIUM 443/tcp   MITM/POODLE 1/8/2015 No update has been released for this particular model. (The manufacturer has released updates for other products, so it may eventually update this line.) Meanwhile, the risk is considered acceptably low, as the device is rarely accessed, and is only reachable from portions of BNL, and the 2 or 3 potential users all use browsers that themselves will not allow the TLS/SSL downgrade.  
splat-s60.starp.bnl.gov MEDIUM 443/tcp   3 separate issues:
1) (83875) SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits.
2) (20007) connections encrypted using SSL 2.0 and/or SSL 3.0.
3) (78479) man-in-the-middle (MitM) information disclosure vulnerability known as POODLE
7/5/2014 The device manufacturer has not released updated firmware to correct this, nor are there settings to eliminate this without disabling encryption completely.  
east-s60.starp.bnl.gov MEDIUM 443/tcp   MITM/POODLE 1/8/2015 No update has been released for this particular model. (The manufacturer has released updates for other products, so it may eventually update this line.) Meanwhile, the risk is considered acceptably low, as the device is rarely accessed, and is only reachable from portions of BNL, and the 2 or 3 potential users all use browsers that themselves will not allow the TLS/SSL downgrade.  
east-s60.starp.bnl.gov MEDIUM 443/tcp   3 separate issues:
1) (83875) SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits.
2) (20007) connections encrypted using SSL 2.0 and/or SSL 3.0.
3) (65821)  the use of RC4 in one or more cipher suites.
7/5/2014 The device manufacturer has not released updated firmware to correct this, nor are there settings to eliminate this without disabling encryption completely.  
west-s60.starp.bnl.gov MEDIUM 443/tcp   4 separate issues:
1) (83875) SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits.
2) (20007) connections encrypted using SSL 2.0 and/or SSL 3.0.
3) (78479) man-in-the-middle (MitM) information disclosure vulnerability known as POODLE
4) (65821) use of RC4 in one or more cipher suites.
7/5/2014 The device manufacturer has not released updated firmware to correct this, nor are there settings to eliminate this without disabling encryption completely.  
nplat-s60.starp.bnl.gov MEDIUM 443/tcp   MITM/POODLE 1/8/2015 No update has been released for this particular model. (The manufacturer has released updates for other products, so it may eventually update this line.) Meanwhile, the risk is considered acceptably low, as the device is rarely accessed, and is only reachable from portions of BNL, and the 2 or 3 potential users all use browsers that themselves will not allow the TLS/SSL downgrade.  
nplat-s60.starp.bnl.gov MEDIUM 443/tcp   3 separate issues:
1) (83875) SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits.
2) (20007) connections encrypted using SSL 2.0 and/or SSL 3.0.
3) (65821) use of RC4 in one or more cipher suites.
7/5/2014 The device manufacturer has not released updated firmware to correct this, nor are there settings to eliminate this without disabling encryption completely.  
temperature1.starp.bnl.gov
temperature2.starp.bnl.gov
MEDIUM 502/tcp  23817
 83301
 83302
(three separate Accept Risk rules in Security Center)
Modbus access   This is a very simple device with very little configurability. No sensitive information is available to be read from this device, nor are any hardware systems controlled by this device.
 
cleanroom-sw.starp.bnl.gov MEDIUM 23/tcp  42263 The remote Telnet server transmits traffic in cleartext. 7/2/2015 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
rps1.starp.bnl.gov MEDIUM 23/tcp  42263 The remote Telnet server transmits traffic in cleartext. 4/21/2016 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
rps2.starp.bnl.gov MEDIUM 23/tcp  42263 The remote Telnet server transmits traffic in cleartext. 4/21/2016 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
starvoltmeter1.starp.bnl.gov MEDIUM 23/tcp  42263 The remote Telnet server transmits traffic in cleartext. 5/4/2016 Device is incapable of SSH connections.  No sensitive information is on this device, and it does not have any experimental hardware controls.  It will be removed in the summer of 2016. [allowance set to expire Dec. 1, 2016]
 
starvoltmeter1.starp.bnl.gov MEDIUM 80/tcp 85582 Web app vulnerable to clickjacking 5/9/2016 Risk is acceptable and it is not correctable with this hardware.  No sensitive information is on this device, and it does not have any experimental hardware controls.  It will be removed in the summer or fall of 2016.  [allowance set to expire Dec. 1, 2016]
 
starvoltmeter1.starp.bnl.gov MEDIUM 80/tcp 46194 CGI Path Traversal 5/9/2016 Risk is acceptable and it is not correctable with this hardware.  No sensitive information is on this device, and it does not have any experimental hardware controls.  It will be removed in the summer or fall of 2016.  [allowance set to expire Dec. 1, 2016]
 
tofunps.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
daq-sw2.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
eemccanpower.starp.bnl.gov MEDIUM 23/tcp  42263 The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 1/10/2017: found in scan results again.  No risk acceptance listed in Security Center, so re-added.
npslaser.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
eemc-pwrs1.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
mtdnps.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
tofnps2.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
daq-sw1.starp.bnl.gov MEDIUM 23/tcp  42263 The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
daq-sw1.starp.bnl.gov MEDIUM 80/TCP  85582 Potentially Vulnerable to Clickjacking (no X-Frame-Options response header) 05/18/2018 The embedded web server on this network switch is not configurable in a way that will resolve this. Considering that firewall rules generally prevent access to this web interface from outside its subnet, this risk is acceptably low.  
scdaqpower.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
tofnps1.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
tof-hv.starp.bnl.gov MEDIUM 23/tcp   The remote Telnet server transmits traffic in cleartext. 7/2/15 Operational Need: Device does not support SSH connections. Telnet only accessible from limited subnets. No sensitive data is transmitted.
 
splat-s60-2.starp.bnl.gov MEDIUM 443/tcp   4 separate issues:
1) (83875) SSL/TLS connections with one or more Diffie-Hellman moduli less than or equal to 1024 bits.
2) (20007) connections encrypted using SSL 2.0 and/or SSL 3.0.
3) (78479) man-in-the-middle (MitM) information disclosure vulnerability known as POODLE
4) (65821) use of RC4 in one or more cipher suites.
7/5/2014 The device manufacturer has not released updated firmware to correct this, nor are there settings to eliminate this without disabling encryption completely.  
onlpool-s60-01.starp.bnl.gov
onlpool-s60-02.starp.bnl.gov
 MEDIUM  23/tcp  42263  Telnet server  4/28/2016 Though it accepts connections, it only displays a banner stating that it is disallowed, and immediately disconnects.  
onlpool-s60-02.starp.bnl.gov MEDIUM 80/tcp 85582  Potentially vulnerable to clickjacking (no X-Frame-Options) 1/10/2017 This device has no configuration option available to mitigate or eliminate this issue.  
alh2.starp.bnl.gov  MEDIUM 16992/tcp  85582 Web app vulnerable to clickjacking  5/31/2016 Risk is acceptable.  This is a very rarely used (but useful when needed) Intel AMT interface (beneath the Operating System), where it is not correctable.  
daq-sw1.starp.bnl.gov
daq-sw2.starp.bnl.gov
cleanroom-sw.starp.bnl.gov
 MEDIUM 60000/tcp  42263  Telnet server  6/1/2016 Cannot disable telnet on these devices' Broadcom FASTPATH version (tried), nor is SSH available.  We however do not use telnet to interact with these devices, so the danger of intercepted plain text login credentials and such is zero.  
130.199.61.255  MEDIUM 23/tcp  42263  Telnet server 6/8/2016 This is a strange case.  This IP address is the broadcast address for the subnet.  The device that is connecting is an instrumentation device that appears to be properly configured to use 130.199.60.54, yet is answering to the broadcast address.
Meanwhile, the device has a Telnet toggle option to disable telnet, but it does not work - it continues answering telnet despite restarts.  In any case, the users do not use the telnet interface, thus the risk of this is considered acceptable.
 
tpcanodehv.starp.bnl.gov MEDUIM 22/TCP 90317 SSH weak algorithms supported (arcfour) 10/17/2016 The encryption algorithms are not configurable.  The system is not widely accessible even with in the BNL campus, and SSH will only rarely be used with this device.  
star-design.star.bnl.gov HIGH 445/TCP 36087 Autodesk IDrop ActiveX Control Heap Corruption 04/25/2017 The contents of IDrop.ocx have been deleted, leaving the empty file in place to prevent Autodesk from recreating it.   
ovirt1.star.bnl.gov MEDIUM 443/TCP 40984 Browseable web directories 12/13/2016 This behaviour is intentional and does not expose any sensitive information.  
sc.starp.bnl.gov MEDIUM 9812/TCP and 4812/TCP (two separate Nessus results) 12085 Tomcat default files 05/16/2018 The risk this adds is acceptably low, as very little information is actually returned in the response. Furthermore, this is not a full-blown Tomcat installation, and it does not have the usual web.xml to add custom error pages.  
lecroyabsw.starp.bnl.gov MEDIUM 23/TCP  42263  Telnet server 11/29/2018 This hardware hardware does not have SSH access and we actively use the telnet access for monitoring the device.  The device is on a firewalled subnet dedicated to our experiment's operations, so access is limited and the risk is considered acceptable.  
lecroyabsw.starp.bnl.gov MEDIUM 23/TCP  42263  Telnet server 01/07/2019 This instrumentation does not have SSH access.  This device is on a firewalled subnet dedicated to our experiment's operations and hosts no sensitive information.  We consider the risk of operating this device as is to be acceptably low.  
l402-onl.starp.bnl.gov HIGH    3316 anonymous account w/o password 08/27/2021 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  
l403-onl.starp.bnl.gov MEDIUM    3316 anonymous account w/o password 08/27/2021 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  
l404-onl.starp.bnl.gov MEDIUM   3316 anonymous account w/o password 08/27/2021 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  
onldb3.starp.bnl.gov MEDIUM    3316 anonymous account w/o password 08/27/2021 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  
onldb4.starp.bnl.gov MEDIUM    3316 anonymous account w/o password 08/27/2021 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  
xeon-phi-dev.starp.bnl.gov MEDIUM    3316 anonymous account w/o password 08/27/2021 Operational Need: Anonymous access is read-only by configuration. No sensitive information is available. Access is needed for monitoring of experiment operations.  

 

The passwordless accounts ("root" and "anonymous") are only distinguished in the details of each finding -- our comments sometimes address root when anoymous is found or vice versa.

Some db nodes have no marked findings (as of 3/31/2014, but not an exhaustive check):  robinson, heston (despite being listed above), duvall/db09 (alias), omega.

 

Nodes with CFEngine Deployed

This is a list of nodes that have CFEngine deployed. 

[This list has not been well maintained over the years, though some updates have been done sporadically.  It should not be considered reliable.]

IP Address: Hostname: Operation System: Online: Offline: CFEngine:
130.199.60.153 onlam3.starp Scientific Linux 6   Online Policy Hub
130.199.60.57 onlldap.starp Scientific Linux 6  
130.199.60.12 onl01.starp Scientific Linux 7  
130.199.60.13 onl02.starp Scientific Linux 7  
130.199.60.18 onl03.starp Scientific Linux 7  
130.199.60.37 onl04.starp Scientific Linux 7  
130.199.60.38 onl05.starp Scientific Linux 7  
130.199.60.42 onl06.starp Scientific Linux 7  
130.199.60.49 onl07.starp Scientific Linux 7  
130.199.60.56 onl08.starp Scientific Linux 7  
130.199.60.100 onl09.starp Scientific Linux 7  
130.199.60.101 onl10.starp Scientific Linux 7  
130.199.60.102 onl11.starp Scientific Linux 7  
130.199.60.103 onl12.starp Scientific Linux 7  
130.199.60.104 onl13.starp Scientific Linux 7  
130.199.60.105 onl14.starp Scientific Linux 7  
130.199.60.187 onl15.starp Scientific Linux 7  
130.199.60.194 onl16.starp Scientific Linux 7  
130.199.60.195 onl17.starp Scientific Linux 7  
130.199.60.196 onl18.starp Scientific Linux 7  
130.199.60.197 onl19.starp Scientific Linux 7  
130.199.60.198 onl20.starp Scientific Linux 7  
130.199.60.200 onl21.starp Scientific Linux 7  
130.199.60.201 onl22.starp Scientific Linux 7  
130.199.60.202 onl23.starp Scientific Linux 7  
130.199.60.204 onl24.starp Scientific Linux 7  
130.199.60.208 onl25.starp Scientific Linux 7  
130.199.60.209 onl26.starp Scientific Linux 7  
130.199.60.210 onl27.starp Scientific Linux 7  
130.199.60.211 onl28.starp Scientific Linux 7  
130.199.60.212 onl29.starp Scientific Linux 7  
130.199.60.213 onl30.starp Scientific Linux 7  
130.199.60.224 cephmon01.starp Scientific Linux 7  
130.199.60.242 cephmon02.starp Scientific Linux 7  
130.199.60.136 deneb.starp Scientific Linux 7  
130.199.60.233 mongodev01.starp Scientific Linux 6  
130.199.60.234 mongodev02.starp Scientific Linux 6  
130.199.60.235 mongodev03.starp Scientific Linux 6  
130.199.60.237 etof-cr.starp Scientific Linux 7  
130.199.60.231 mq01.starp Scientific Linux 7  
130.199.60.232 mq02.starp Scientific Linux 7  
130.199.60.160 mq03.starp Scientific Linux 6  
130.199.60.161 mq04.starp Scientific Linux 6  
130.199.60.133 blanchett.starp Scientific Linux 6  
130.199.60.204 burton.starp Scientific Linux 6  
130.199.60.86 daqman.starp Scientific Linux 6  
130.199.60.166 rts01.starp Scientific Linux 6  
130.199.60.88 dbbak.starp RHEL 6  
130.199.60.91 dashboard1.starp RHEL 6  
130.199.60.44 trgscratch.starp Scientific Linux 6  
130.199.60.36 sclrscratch.starp Scientific Linux 6  
130.199.60.179 gmt-ops.starp Scientific Linux 6  
130.199.60.126 l3display.starp Scientific Linux 7  
130.199.60.150 stardns1.starp Scientific Linux 6  
130.199.60.93 stargw3.starp Scientific Linux 6  
130.199.60.74 stargw4.starp Scientific Linux 6  
130.199.60.76 stargw5.starp Scientific Linux 6  
130.199.60.19 beatrice.starp Scientific Linux 6  
130.199.60.142 startrg.starp Scientific Linux 6  
130.199.60.60 eemc-spin.starp Scientific Linux 6  
130.19.60.246 l4evp.starp Scientific Linux 6  
130.199.60.248 xeon-phi-dev.starp Scientific Linux 6  
130.199.60.53 astaire-run09.starp Scientific Linux 6  
130.199.60.68 chaplin-run09.starp Scientific Linux 6  
130.199.60.25 eemc-sc.starp Scientific Linux 6  
130.199.61.176 emc02.starp Scientific Linux 6  
130.199.60.32 evp.starp Scientific Linux 6  
130.199.60.124 fms-hv2.starp Scientific Linux 6  
130.199.60.70 onldb.starp Scientific Linux 7  
130.199.60.89 onldb2.starp Scientific Linux 7  
130.199.60.165 onldb3.starp Scientific Linux 7  
130.199.60.203 onldb4.starp Scientific Linux 7  
130.199.60.29 onldb5.starp RHEL 6  
130.199.60.80 onldb6.starp RHEL 6  
130.199.61.167 rts02.starp Scientific Linux 6  
130.199.60.52 rts04.starp Scientific Linux 6  
130.199.60.69 sc.starp.bnl.gov Scientific Linux 7  
130.199.60.125 sc2.starp.bnl.gov Scientific Linux 6  
130.199.60.78 sc5.starp.bnl.gov Scientific Linux 6  
130.199.60.51 softioc4.starp Scientific Linux 6  
130.199.60.63 tofcontrol.starp Scientific Linux 6  
130.199.60.5 tofp.starp Scientific Linux 6  
130.199.60.21 eemc-testdaq.starp Scientific Linux 6  
130.199.60.55 bermuda.starp Scientific Linux 6  
130.199.60.46 barbados2.starp Scientific Linux 6  
130.199.60.41 alh2.starp Scientific Linux 6  
130.199.60.173 mtd-cr.starp Scientific Linux 6  
130.199.60.134 itpc01.starp Scientific Linux 6  
130.199.60.214 daqboot.starp Scientific Linux 6  
130.199.148.93 duvall.star RHEL 6   Offline Policy Hub
130.199.59.200 sun.star RHEL 6  
130.199.148.86 fc1.star Scientific Linux 6  
130.199.148.87 fc2.star Scientific Linux 6  
130.199.148.88 fc3.star Scientific Linux 6  
130.199.148.89 fc4.star Scientific Linux 6  
130.199.148.134 fc5.star Scientific Linux 7  
130.199.148.101 db01.star Scientific Linux 7  
130.199.148.102 db02.star RHEL 6  
130.199.148.104 db04.star RHEL 6  
130.199.148.105 db05.star Scientific Linux 7  
130.199.148.106 db06.star Scientific Linux 7  
130.199.148.107 db07.star Scientific Linux 7  
130.199.148.108 db08.star Scientific Linux 7  
130.199.148.110 db10.star Scientific Linux 7  
130.199.148.111 db11.star Scientific Linux 7  
130.199.148.112 db12.star Scientific Linux 7  
130.199.148.113 db13.star Scientific Linux 7  
130.199.148.114 db14.star Scientific Linux 7  
130.199.148.115 db15.star Scientific Linux 7  
130.199.148.116 db16.star Scientific Linux 7  
130.199.148.117 db17.star RHEL 6  
130.199.148.18 db18.star RHEL 6  
130.199.148.91 heston.star RHEL 6  
130.199.148.92 omega.star RHEL 6  
130.199.59.199 sunbelt.star RHEL 6  
130.199.148.90 robinson.star RHEL 6  
130.199.148.133 robinson2.star Scientific Linux 7  

 

As deployed, for online nodes I have CFEngine running on onlam3.starp. I have a script cf-install.sh which is just the following 4 lines
#!/bin/bash
wget -N -P /root/ http://onlam3.starp.bnl.gov/cfengine-community-3.10.4-1.el6.x86_64.rpm
/bin/rpm -i /root/cfengine-community-3.10.0-1.el6.x86_64.rpm
/var/cfengine/bin/cf-agent --bootstrap 130.199.60.153

NOTE: as of late 2020, onlam3 is
no longer in service.  For these purposes, it has been replaced by onlcs.starp.bnl.gov (130.199.60.57)

Offline nodes use duvall.star. The script above will work if you correct the wget, and IP to point to duvall

NOTE: STAR is now using CFEngine-3.10.0-1.el6.x86_64.rpm on Online & Offline nodes both SL6/RH6 & SL7/RH7. Do not attempt to install CFEngine-3.3.9-1.x86_64.rpm as the client will be unable to bootstrap to the policy hub.

This script will grab the CFEngine package, install it, and bootstrap it to the policy hub.
If you want to create a new policy you just create a .cf file in /var/cfengine/masterfiles on the policy hub, and then add it to the promises.cf file in the same directory. (Caution: A single typo, or incorrect syntax in ANY cf file will result in EVERY policy not applying. This is CFEngine's failsafe to prevent server crashes, or damage to production files) The logs for every system are kept in that system's /var/cfengine directory. The log filename is cf3.HOSTNAME.runlog Unfortunately the logs do not get centralized on the policy hub, although I suppose a policy can be created to copy them to a central location.

Policies currently run every 10 minutes. Some policies use wget to grab a file from the policy hub's web server, so they make an HTTP connection every five minutes. They don't appear to grab the file every time, unless the local file doesn't match the one on the server (last modified date). I'm going to work on a more elegant solution for this in the future, but for now it doesn't cause any harm, and the files are small, so it isn't using a lot of bandwidth.

Nodes with CephFS mounted

This is a list of nodes that have the CephFS Client installed and CephFS mounted

IP Address: Hostname: Ceph Native Ceph Fuse    
130.199.60.86 daqman.starp      
130.199.60.32 evp.starp      
130.199.61.104 burton.starp      
130.199.162.175 ovirt1.star      
130.199.162.133 ovirt2.star      
130.199.162.139 ovirt3.star      
130.199.162.134 ovirt-engine.star      
130.199.60.88 dbbak.starp      
130.199.162.136 dean.star      
130.199.162.174 dean2.star      
130.199.60.165 onldb3.starp      
130.199.60.203 onldb4.starp      
130.199.60.88 dbbak.starp      
130.199.60.231 mq01.starp      
130.199.60.232 mq02.starp      
130.199.60.69 sc.starp      
130.199.61.9 cephnfs.starp      
130.199.61.17 cephnfs2.starp      
130.199.60.246 l4evp.starp      
130.199.60.70 onldb.starp      
130.199.60.44 trgscratch.starp      
130.199.60.12 onl01.starp      
130.199.60.13 onl02.starp      
130.199.60.18 onl03.starp      
130.199.60.37 onl04.starp      
130.199.60.38 onl05.starp      
130.199.60.42 onl06.starp      
130.199.60.49 onl07.starp      
130.199.60.56 onl08.starp      
130.199.60.100 onl09.starp      
130.199.60.101 onl10.starp      
130.199.60.102 onl11.starp      
130.199.60.103 onl12.starp      
130.199.60.104 onl13.starp      
130.199.60.105 onl14.starp      
130.199.60.187 onl15.starp      
130.199.60.194 onl16.starp      
130.199.60.195 onl17.starp      
130.199.60.196 onl18.starp      
130.199.60.197 onl19.starp      
130.199.60.198 onl20.starp      
130.199.60.200 onl21.starp      
130.199.60.201 onl22.starp      
130.199.60.202 onl23.starp      
130.199.60.204 onl24.starp      
130.199.60.208 onl25.starp      
130.199.60.209 onl26.starp      
130.199.60.210 onl27.starp      
130.199.60.211 onl28.starp      
130.199.60.212 onl29.starp      
130.199.60.213 onl30.starp      

Recommended settings for key nodes

The following set of recommendations applies to mission critical systems in use in STAR. Mission critical systems are here defined as nodes hosting a service critical to the operation of STAR analysis, data production and/or run support. This definition would include services and nodes such as a Web server, a database servers, a gatekeepers under STAR control's and/or nodes hosting special services used in STAR's.

The rational behind a base set of rules is multiple:

  • Ease of re-deploy and backup of systems can be made if standard directories are assumed and known
  • Detection and tracing of changes is made easier if files and local scripts are kept in standard places (in fact, any creation of files and/or directories in different trees would then become suspicious).
  • Sharing the burden of management is made easier if all comply with the base rules and hence, knows the "what should be where" (minimize time waste to detect what was done and changed by a secondary administrator).
  • Minimize risks and create layers of responsibilities.

The recommendations are broken into the following sub-sections:

 

Access to root account and basic structure & rules

Responsible personnel, password versus key based access

The node registration should clearly display a primary and a secondary contact person for a mission critical node. Both names may have access to the root account using password access. There shall e no other password based access to the root account granted: only SSH key based access should be allowed and managed by the SSH Key Management system.

Each key should supply a key owner field (user@node or user) for easier visual identification of key provenance. SSH tracing should be enabled to allow session based login [Wayne, more precision needed here].

Administrators accessing a mission critical node are expected to

  • keep the primary administrators aware of changes they may perform and document changes
  • do NOT add components or alter setting of services under the control or responsibilities of dedicated service administrator without notice to the service administrator. For example, an upgrade of the Web server service (httpd) should be preceded with a notice to the Web master and administrator.
  • The courtesy rule above may be altered in emergency situations during which, changes should be documented and sent to the system's responsible personnel upon completion of the emergency procedure.

Directory locations

The root account home directory should be set to /root. The following directories should be used

  • /root/bin or /root/scripts - should be used for any additional scripts developed for either command line administrative or cron based tasks
  • /root/Software - should be used for leaving installation files and/or packages installed from source. The following sub-structure are base examples
    • rpm/ - a sub-directoy containing all downloaded rpm
    • underway/ - a directory where packages are being unpacked, compiled, tested and assembled. This sub-directory could contain package archives until such a time the package is Installed and operational.
    • Installed/ - a directory containing a copy of installed packages' archive (.tar.gz, .zip etc...)
    • perl/ - a sub-directory for perl related modules and code. This tree would have an additional level following the convention above. A sub-directory modules/ would exists containing the pre-compiled (and installed) perl modules in case a quick re-install is needed from source.
    • Self contained packages (such as perl) may follow a similar rule.
      • A sub-directory under Software/ must clearly and non-ambiguously indicate the package or component name
      • The structure underneath should reflect the structure outline above as for the perl/ example

      For example, if there is a need to confine all Drupal related component into its own source tree, simply create a /root/Software/Drupal and place underneath a structure such as rpm/ modules/ etc ...

  • /root/backup/ - a sub-directory where miscellaneous backups of the node's contents are placed.

Other directory rules

  • There should be no logs, reports, notes or other document under slash "/"
  • There shall be no other directories than under "/" than what is described below (/opt, /home)
  • /home/users should be used for holding local user's directories if any
    • number of local users should be kept to the strict minimum on mission critical nodes (ideally, none should be used)
  • /opt may be created from slash and contain optional packages (rt2, tivoli, vendor specific optional components are examples) as well as a holder of the cluster wide OPTSTAR code and packages if applies.
  • For te root account and if a script is used and needs a temporary space, /tmp should NOT be used for security reasons
    • Instead, /usr/local/tmp should be used (created)
    • Its ownership/protection should be strictly root:root and u:rwx (no access for others)
  • /usr/local/etc, /usr/local/share and other standard sub-directories should be used for home made tools in need of local configuration.
  • /etc/smrsh/ should contain Email pipe related scripts - those should NOT reside under /root/bin/ .

 

Process and services and access to non-root accounts

Access to non-root account should follow the following rule:

  • Services should be run under non-root local accounts. Use of secondary groups could be used to create privilege separation layer.
    For example:

    • mysql service should be started under the mysql account
    • A Web server would start under the starweb account
      • starweb would belong to the primary group rhstar
      • a secondary group webadmin could be assigned
    • A web administrator would log under a webman account belonging to the secondary group webadmin
      • ... and share files with the httpd process running under starweb with group access granularity.
      • All work and modifications would be done through webman, group access would not have w=write access to most files.
  • Only SSH key access should be used for process/service related account
  • Control of access should be managed by the SSH Key Management system. This would allow to keep track of who is able to access the servce account.

non-root account used for running services should assume the following rule of thumbs:

  • There will be one primary responsible owner of non-root service account (for example, only one Web master). Other requesting access would warrant an explicit approval by the primary owner of the account. Access to others would be revoked by the primary owner upon request.
  • Site admins would inform primary owner of non-root accounts of changes and/or upgrade needed and directly affecting their responsibility and service

 

History settings

The following scheme is suggested:

  • History listing should be set to at least 10k entries
  • History should display timestamps
  • Mechanism should be in place to allow identifying history by session (PID)

To satisfy those requirements, the following scripts should be placed in /etc/profile.d/

history.sh

#
# Set history format and location
#
HISTSIZE=10000
HISTTIMEFORMAT=1

if [ ! -d "$HOME/.history" ]; then
/bin/mkdir -p $HOME/.history
fi
HISTFILE=$HOME/.history/history.$$

history.csh

#
# Set history format and location
#
setenv HISTSIZE 10000
setenv HISTTIMEFORMAT 1

if ( ! -d "$HOME/.history" ) then
/bin/mkdir -p $HOME/.history
endif
setenv HISTFILE $HOME/.history/history.$$

Accounting and change detection mechanisms

Accounting

To help the findings of problems, accounting should be enabled using the standard Unix accounting service (psacct). This will allow the use of the lastcomm command as well as the last command (the later is possible without accounting).

Host integrity and change detection

At maximum one tool for detecting changes made to the system core components of the system should be installed (currently in use WatchFrog or Osiris). Area of control must

  • include /etc/, /usr/sbin/, /bin, /usr/bin/, /usr/local, /usr/local/bin/, /usr/local/etc/, /usr/sbin/, /boot/, /root/bin/ where path/ denotes the full content found recursively and path denote detection of changes within the specified directory level.
  • exclude frequently modified files so report remain meaningful - for example, /etc/ntp.drift would be excluded and so would be a backup log file
  • include the service components and content the node hosts - for example, a Web server would have the change detection monitor /var/www/ (as a side note, database content cannot be monitored as new entries would trigger the detection of a change).

Host integrity reports should be sent to the primary root account responsible personnel.

Backup and data safety

There should be at least one backup service running on mission critical systems. Key content should be backed up in a minimal yet complete manner. Examples include:

  • a Web server would see the /var/www/html tree back-up along key configuration files.
  • A node hosting Hypernews should save the Email content and archive
  • A database server content backup procedure may involve a two stage process whereas one step would perform a mysqldump and a backup process collect the dump snapshots.

backups should avoid saving generic system files such as the one on /bin or /usr/bin .

 

STAR CFEngine policies

 

First stab at a CFEngine policy list and applicability.   The complexity is an initial guess at this point.

 

Policy description Complexity Online SMAF Working Policy? Comments
           
/etc/DOE_banner present easy I'm using issue.net instead of DOE_banner but the text is the same
banner in /etc/issue and /etc/issue.net easy I only edit the text in issue.net but that is all that matters
ordo installed (working / configured) ?  
SL: yum configuration files point to local mirror (will vary with SL version, based on built-in CFEngine classes) medium-hard? most  few        √

Most SMAF nodes have RHEL using the BNL RHN satellite server, rather than yum repos.  Only a few online nodes have RHEL.

The policy will only do something if specific versions of SL are detected.

RHEL/SL 5:  sendmail-cf package installed easy This is part of the general sendmail policy
RHEL/SL 5:  sendmail SMART_HOST set to bnl.gov (/etc/mail/sendmail.mc) easy  √ This is part of the general sendmail policy. Adds the line 'define(`SMART_HOST', `bnl.gov')dnl
RHEL/SL 6:  Postfix relayhost = bnl.gov (/etc/postfix/main.cf) easy  Adds the line relayhost = bnl.gov
SSHD protocol 2 easy Protocol 2 is set by default at this point, but can't hurt to ensure it.
SSHD banner displaying /etc/DOE_banner easy I'm using /etc/issue.net but the banner is the same
SSHD VERBOSE logging easy  

GUI (X Windows) login banner

(See here: [GDM - X Windows login banners] )

hard  
/etc/login.defs: PASS_MIN_LENGTH 8 easy  
/etc/login.defs: PASS_MAX_DAYS 365 easy   not necessarily enforced on all accounts, just setting the default for new accounts
/etc/login.defs: PASS_MAX_DAYS 180 easy   not necessarily enforced on all accounts, just setting the default for new accounts
SKM RPMs installed (exactly which RPMs depends on SL/RHEL version and 32/64 bits)  easy-medium  The client will install but an admin still needs to add it to the console manually.
/etc/logwatch/conf/logwatch.conf: MailTo = wbetts@bnl.gov easy Adds the line MailTo = wbetts@bnl.gov to /etc/logwatch/conf/logwatch.conf
/etc/logwatch/conf/logwatch.conf: MailFrom = LogWatch easy Adds the line MailFrom = Logwatch to /etc/logwatch/conf/logwatch.conf 
/etc/logwatch/conf/logwatch.conf: Detail = 10 easy  Adds the line Detail = 10 to /etc/logwatch/conf/logwatch.conf
smartd configured? (has to know specific device names, plus possibly hardware specific details) hard - very hard? Using DEVICESCAN to allow a universal config.
mdadm/mdmonitor configuration ?  √ for systems with software RAID - simple configuration to set MAILADDR and MAILFROM
osiris client installed w/ firewall rules medium-hard Osiris can be installed, but adding the client to the monitoring master is not possible to automate. Also the firewall rules is a separate policy file so that the rules can be adjusted independently.
ganglia installed and configured medium

currently using different online and offline Ganglia versions with different gmetad/gmond listeners (dean vs. orion) and offline still uses some mcast? 

disk space monitor (perl-Filesys-Df RPM, script and cron setup) medium Using a custom shell script that is pulled from the CFEngine policy hub. It will e-mail STARSupport if a partition is 90%> full
logs to ITD easy  √ Adds the line "*.* @secadm3.itd.bnl.gov" to send log messages to ITD
ntp to use BNL clockservers easy   modifies /etc/ntp.conf to use BNL clockservers. Used on offline network
ntp to use daqman+BNL clockservers easy  √   Modified /etc/ntp.conf to use BNL and daqman clockservers. Used on starp network
enable nscd easy   makes sure the NSCD service is always running and is added to chkconfig.
ethcheck scripts for link speed monitoring easy-medium  √ deploys a script to /root/bin/ to ensure the link speed is in a optimal state.
/etc/resolv.conf uses daqman and stardns1 easy    √ Adds the lines
search starp.bnl.gov
nameserver 1301.199.60.86
nameserver 130.199.60.150
to /etc/resolv.conf
 
/etc/resolv.conf uses BNL nameservers easy    √

branches based on DL1 or DL2 (if subnet 54 is on DL2)

rpm query list dump - SL/RH6  easy   runs rpm -qa | sort >  /var/log/rpmlist/$(sys.cdate)
once every day. Needed in case an rpm database is lost.
 
ypbind service running on onl01 - 60 & stargw{1,2} easy  √    √ Ensures the ypbind service is always running
garabage cleanup  easy    √ Deletes logs that are older than 90 days in /var/cfengine/outputs.
Also deletes logs in /var/log/rpmlist that are older than 60 days for SL/RH6 (refer to rpmlist policy)
 
colorls.sh & colorls.csh modified  medium  √    √ Modifies the colorls.sh & color.csh script. Changes the 'ls' alias to lsc. When entering 'ls' command in large colorful directories, the machine will hang. Policy disables colors for ls command on every machine in every directory. If colors are needed enter 'lsc'
iptables firewall rules applied         This policy applys rules for osiris and ssh using the edit_line feature of CFEngine.
           
STAR environment (lots of individual pieces here) hard - very hard some   X This policy would be extraordinarily difficult to accomplish via CFEngine, so we are not going to attempt this via CFEngine. (It may be revisited at a later date though)