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-Complete-v0.7 was submitted for DOE Cyber Security review of our CSPP on July 19th 2006.
- 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.
- 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 - STAR-General-WorkstationsPolicy_XP
Date: 2006/10/24
Contributors: Jerome Lauret & Wayne Betts (leads), Valeri Fine
- 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
- STAR Operational Need Policy XP
- 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 ...
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
- ...
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.- Extracted topics
- The Run VII preparation page (and notes from referenced meetings wherever available and especially meetings #3, #5, #7, #8)
- You do not have access to view this node slide 14 to 17
- You do not have access to view this node slides 24 to 27
- Online and Offline Computing (STAR Critique) slides 10 to 13
2008 documents
This page will have security related documents and policy previews.
The current list is:
- skype usage policy (08/04/2008)
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 |
Justification |
|
STARGRID01.RCF.BNL.GOV |
130.199.180.111 |
20000-30000 |
Extension |
2009/05/20 |
2015/06/11 |
This conduit is for the STAR RHIC users, in particular, those collaborators that are using Grid software. |
|
|
STARGRID01.RCF.BNL.GOV |
130.199.180.111 |
2811 |
Extension |
2005/02/14 |
2015/06/11 |
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 |
130.199.180.111 |
2135 |
Extension Owners: John Hoover / Wayne Betts |
2005/02/14 |
2015/06/11 |
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 |
130.199.180.111 |
2119 |
Extension Owners: John Hoover / Wayne Betts |
2005/02/14 |
2015/06/11 |
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 |
2008/07/10 |
2015/10/07 |
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 |
The conduit's purpose is to provide computer status and usage |
|
| 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 |
130.199.60.70 |
3501-3503 |
Extension |
2007/01/20 |
2015/04/18 |
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. |
|
| 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 |
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 |
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 |
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 |
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 |
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/01/04 |
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 |
2010/09/25 |
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 |
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. |
|
|
CH2LINUX.STAR.BNL.GOV |
130.199.162.131 |
8080 |
Obsolete |
2006/08/23 |
2007/08/24 |
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 |
ANY |
This server will be a replacement for ch2linux This conduit is for the |
|
DEAN.STAR.BNL.GOV |
130.199.162.136 |
443 |
Extension |
2007/02/23 |
2015/03/20 for the www alias. |
ANY |
(same as above) |
|
DEAN.STAR.BNL.GOV |
130.199.162.136 |
8649 |
Extension |
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 |
|
ROBINSON.STAR.BNL.GOV |
130.199.59.230 |
3336 |
Extension Owners: Jerome Lauret / Wayne Betts |
2009/07/23 |
2013/09/28 |
128.55.36.0 255.255.255.0 |
[IN-BOUND 128.55.36.0 255.255.255.0]
|
|
ROBINSON.STAR.BNL.GOV |
130.199.59.230 |
3306 |
Extension Owners: Jerome Lauret / Wayne Betts |
2012/11/02 |
2014/08/11 |
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). |
|
|
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). |
|
|
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. |
|
|
AUTEUIL.STARP.BNL.GOV |
130.199.60.137 |
to port 7778 |
New |
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 |
New |
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). |
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 |
| 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 |
| mq03.starp (to become new mq01) | 17.05.06-00 |
| mq04.starp (to become new mq02) | 17.05.06-00 |
| 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.
| 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 - basic structure & rules
- Processes and services access to non-root accounts
- History settings should be standard
- Accounting and change detection mechanism
- Backup and data safety
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) |