On The Fly Management of UNIX Hosts Using CFEngine

1. On The Fly Management of UNIX Hosts Using CFEngine Ryan Adamson

2. Introduction • Overview of CFEngine • Overview of ORNL’s Device Management Systems • Configuration Management with CFEngine • Customized Reporting with CFEngine

3. CFEngine Overview • CFEngine -- What is it? • “Cfengine is an autonomic maintenance system not merely a change management roll-out tool.” • Straight from cfengine.org • In general, computers are members of different classes • Depending on class membership, the appropriate policy is applied

4. CFEngine Overview • Hard coded class membership is tough to maintain • An example: • If the hostnames change or machines are added/deleted, we have to manually change the classes in CFEngine

5. ORNL Device Management • NetReg (Network Registration) • End user can register and modify device information at will • DES (Device Exception System) • End user can request exceptions to security policy for valid business reasons • CSR (Cyber Security Reports) • Reports to the end user on overall compliance • CFEngine reports compliance to the CSR

6. ORNL Device Management Topology

7. CFEngine @ ORNL • Goals • Provide a framework for the automated management of systems on the ORNL network • Provide additional reporting capabilities to aid in cyber threat mitigation • Design Philosophy • Be Flexible • Be Robust • Be Polite

8. CFEngine @ ORNL - Design • The Wrong Way

9. CFEngine @ ORNL - Design CFEngine Installations at ORNL by Distribution

10. CFEngine @ ORNL - Design • Flexibility • Different packaging formats • Modular code • Separate out policy files • Screensaver locking (Gnome/KDE) • Patching • Centralized syslogconfiguration • Directory structure for each OS

11. CFEngine @ ORNL - Design • Robustness • Change detection: • Hostname • Hardware • Network Configuration • Device Registration • OS • Scalability • Client check-ins are distributed • Separate back end database server • Geographic distribution of servers

12. CFEngine @ ORNL - Design • Politeness • Limit invasive configuration management • Patching • Syslog configuration • Screensaver • Local and centralized snapshots of modified files • CPU Intensive tasks are done at night • Packages are easy to install • Statically compiled Solaris packages • Centralized download location • ORNL Distributed RHN package

13. CFEngine @ ORNL - Implementation • The Old Way

14. CFEngine @ ORNL - Implementation • Question: For any given device, what policies do we apply? ORNL Policy Standards + OS Specific Requirements + Device Type Specific Requirements – DES Exceptions Applicable policies

15. CFEngine @ ORNL - Implementation • Question: How do we do that? • Scripts gather information from DES and NetReg and store into local database tables • Another local database table has configuration standards information: • Bitwise arithmetic to the rescue!

16. CFEngine @ ORNL - Implementation • Example: Fedora 10 desktop with Screensaver exception • Screensaver policy not enforced in this case, but other device requirements are

17. CFEngine @ ORNL - Implementation • A directory is created for each client • Empty text files with the names of classes to be turned on • Each file corresponds to an appropriate policy needed for the client • Example: Fedora 10 desktop with Screensaver exception • Text files in its directory would be: • Autopatch • Syslog

18. CFEngine @ ORNL • Automatically generates a class list for each client on a recurring basis • Advantages: • Changes in baseline policy, os type policy, or exceptions for individual clients are immediately propagated • Disadvantages: • Extra complexity

19. CFEngine @ ORNL - Reporting • CFEngine automatically reports: • Packages installed with native package manager • Versions of packages installed • Compliance with ORNL standards • Users and Groups • Hardware information • And can be configured to report almost anything else

20. CFEngine @ ORNL - Reporting • Our modified CFEngine database allows us to dynamically reference data collected from • CFEngine • DES • NetReg • WHOs database of personnel • All of these are stored as relational tables in the CFEngine DB keyed on a unique identifier • SQL queries are used to retrieve meaningful data

21. CFEngine @ ORNL – Reporting Example • We need to notify everyone running Fedora 9 that their OS will no longer be supported • Run a customized query • Find all Fedora 9 computers • Cross-Index these computers with NetReg to find the system owners • Cross-Index the system owners with WHOs to find their email addresses

22. CFEngine @ ORNL – Reporting In Style • What if we don’t like using a command line? • LCARS offers a web interface for quick browsing • Laboratory • Computer • Autonomic • Reporting • System • Not to be confused with LCARS:

23. CFEngine @ ORNL – Reporting In Style

24. CFEngine @ ORNL – Still Flexible • CFEngine @ ORNL offers • Flexible and robust configuration management • Simple reporting tools • Powerful data aggregation • But, it has been designed so that new features, policies, and reports can be implemented quickly and easily

25. CFEngine @ ORNL • Questions? Don’t forget the BoF session afterwards!

26. Other ORNL presentations which might be of interest • SharePoint • Monday, 11:45-Using SharePoint UI to Deliver General Use Applications, Connie Begovich • Tuesday, 11:45-SharePoint at ORNL, Brett Ellis • Cyber Security • Monday, 1:30-Development of a Process for Phishing Awareness Activities, Phil Arwood • Monday, 2:15-How I Learned to Embrace the Chaos, Mark Lorenc • Monday, 4:15-TOTEM:The ORNL Threat Evaluation Method,John Gerber/Mark Floyd • Desktop Management • Monday 4:15-On the Fly Management of UNIX Hosts using CFEngine,Ryan Adamson • Tuesday, 11:00-Implementation of Least User Privileges, Doug Smelcer • Wednesday, 11:45, Microsoft Deployment Using MDT and SCCM, Chad Deguira • Incident Management • Wednesday, 11:00-Helpdesk Operations for Clients Without Admin Privileges, Bob Beane/Tim Guilliams • IT Modernization • Monday, 2:15-12 Months of Technology, Lara James