A Model for Open Source & System Administration Managing Open Source Software in a Production Environment SANS 2002 Orlando, FL April 2002 Presented by:

A Model for Open Source & System Administration

Managing Open Source Software

in a Production Environment

SANS 2002Orlando, FL

April 2002

Presented by: Mitchell Saba

University of Connecticut, et alStorrs, Connecticut

P.O. Box 817

Storrs, CT 06268

[email protected]

+1 860-486-4994 (Office)

+1 860-428-9883 (cell)

+1 860-429-4059 (fax)

Slide - Slide - 22A Model for Open Source & System AdministrationA Model for Open Source & System AdministrationSANS 2002SANS 2002

Introduction

• What will we cover?

– A brief history of Open Source.

– A comparison of Open Source and Commercial Software.

– A model for Open Source administration practices.


GNU/Open Source Software

• What’s in a name?– GNU

• Established in 1984 to promote free software to combat the growing proprietary choke hold on developers

• Specific Definition

– Open Source• Established in 1998 in reaction to Netscape’s planned

release of its browser source code.• Broad-based definition


What’s The Difference

• GNU– Focus on FREE software– Emphases Freedom

• Similar to a Software Bill of Rights

– Anti-Proprietary

• Open Source– Setup to attract commercial interest– Prompts open development– No emphasis on Freedom


A Brief History of GNU

• Championed by Richard Stallman• Motivation

– To develop a completely free system to combat the move to all proprietary systems

• Methodologies– Free software – as in Freedom

• Develop a complete free system including all the requisite components.

– Use ‘Copyleft’ to protect the GNU Project• Created the GNU General Public License (GNU GPL)• Anti-Copyright: established to keep software free for all users


GNU Free Software Definition

• Freedom 00: • The freedom to run the program, for any

purpose.

• Freedom 01: • The freedom to study how the program works,

and adapt it to your needs. Access to the source code is a precondition for this.


GNU Free Software Definition

• Freedom 10: • The freedom to redistribute copies so you can

help your neighbor.

• Freedom 11: • The freedom to improve the program, and

release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition for this.


A Brief History of Open Source Software

• Championed by– Todd Anderson, Chris Peterson, John "maddog" Hall

Larry Augustin, Sam Ockman, and Eric Raymond.

• Motivations– To leverage the superiority of an open source

development process– To gain the support of the corporate world

• Methodologies– Definition is derived from the Debian Free

Software Guidelines


Setting the Stage

• Presentation Definitions– Open Source

• Either Open Source or GNU software– Software that is either freely available as binaries or source


Success Speaks for Itself

• Open Source Super Stars– GNU/Linux & BSD

• Redhat Linux• IBM is adopting Linux for their platforms• BSD is very robust and known for being ‘secure’• These are a viable alternative to proprietary platforms for

commercial venture support– Google, Tommy Hilfiger, etc.

– Perl & gcc• Very powerful for web applications, system administration tasks,

software development, etc.

– Apache & wu-ftp• Providing user connectivity to remote information and servers


Commercial-Proprietary Software

• Proprietary– “Something that is used, produced, or marketed

under exclusive legal right of the inventor or maker.”4

• Use of Commercial Software– Payment for privilege (for fee)– Grant authorization in lieu of payment

• ZoneAlarm for individuals


Commercial Software Pros

• Pros– Support– Reputation– Dedicated developers– Financial support


Commercial Software Cons

• Cons– No access to the source code– Restrictions writing custom interfaces– Inability to add functionality– Typically requires licensing fees


Commercial vs. Open Source

• At First Glance– Commercial

• Less in-house expertise necessary• High initial costs (purchase & support)• Proprietary lock-in, customer investment already• Higher dependency on external support• Numerous specific certifications


Open Source vs. Commercial

• At First Glance– Open Source

• More in-house expertise necessary• Low initial costs (purchase & support)• Open source flexibility• Little dependency on external support• Fewer available specific certifications• Reliability of ‘other’ source code


Commercial + Open Source

• Commercial hosting Open Source Software?!– IBM web server– BIND


Open Source + Commercial

• Open Source hosting Commercial Software!?– Matlab– ColdFusion


Commercial vs. Open SourceSecurity

• Security Comparison– Open Source - Apache

• Security bugs…– 14 since June 6th 1998!– Rival Xitami has a similar record

– Commercial - IIS• Security bugs

– I lost count around 150 in roughly 1 year!» In all fairness after numerous new releases security

under IIS is getting better» However the poison fruit stigma has attached


Commercial Embrace

• Corporations Embracing Open Source– IBM

• AIX 5L• SuSE distribution agreement• Linux on the Mainframe

– SUN Microsystems• Solaris 8

– DELL• Linux installed servers


Full Circle

• Commercial vs. Open Source– Open Source has proven a threat to commercial

IT vendors– Open Source is improving software products

through competition– Open Source is being hijacked in many ways by

‘corporate sponsors’

• Two questions remain– Is Open Source secure?– What model do we adopt?


The Cryptographic Argument

• Open Source Software = – Scrutiny

• Open Code Reviews

– Fuel for the fire• Need driven development

• Commercial Software =– Dedicated developers

• Closed Code Reviews

– The Black Box, is it really protection?• Reverse engineering

– Samba?


Open Source Expertise

• Administering Open Source Software– Broad based ‘Open Source’ skill set required– The Open Source Skill Set

• System internals• make files• Programming basics

– Language knowledge» Perl, gcc, etc.

– Debugging skills


Slide 22 – SUPPLEMENTAL #1

• System Familiarity

• Basic Commands– ls, rm, df, du, chmod, chown, find, netstat, etc.

• System Tools– vi, man, etc.



• Defining Toolkit– Customize for individual needs

• The sky is the limit– KISS – Keep It Simple Stupid

• All inclusive Toolkit– To cumbersome– Inefficient– Cluttered



• Toolkit Construction– Optimal

• One well oiled• One or two backup tools

– netstat– lsof

• Practiced• SOPs

– Equal insurance



• Toolkit essentials– Well oiled

• Used frequently

– Maintained• Current version/release

– SOP – Standard Operating Procedures• Installation• Configuration• Step-by-step use guide



– The Right Tools• Categories include

– File Verification Utilities» Tripwire

– Access Control» crack, ssh

– Process Examination» pstree

– Installation & System Integrity Verification» rpm, md5, strings

– Automation Tools» Perl, up2date, etc.

– Customized Services


Open Source Expertise

• Administering Open Source software– Routine Tasks

• RPM utilities• Configuration/make file modifications• System configuration issues• Network troubleshooting• Security audits


Commercial Software Expertise

• Administering Commercial Software– Specialized skill set required

• Broad based skill set not as important…• System configuration issues• Software specific knowledge• Network troubleshooting• Security audits


A Matter of ExpertiseThe Common Ground

• The Common Ground• Deployment plans

– Implementation plan– Back out plan– Recovery Plan– Backups (level 0)

• Security considerations• Maintenance

– Upgrades– Patches– Monitoring


An Examination of Open Source Administration

• Definition– Defining Functionality– Defining Use and Access– Defining System Impact– Selecting the Package

• Construction


Defining Functionality

• User request or need– Define necessary functionality

• Specifications– Interview the user to determine specifications

• Compare with original request– Stated needs

• Investigate alternative packages– Is the requested package the best fit?– Do other packages meet multiple requests (broader use)?


Defining Use and Access

• Use– What subset of users will use the package?

• Restrict by– Group– System

– How will they use the package?• How can it be abused?

• Access– What type of access is needed to use the package?

• SSH• Web• SFTP



• New Service Specification– Introduction

• Purpose• Scope• System Overview• Terms & Definitions• References



• New Service Specification– General Information

• Product Function• User Characteristics• Terms of Use• General Constraints• Assumptions & Dependencies



• New Service Specification– Functional Requirements

• Description– Introduction– Required Functionality– Additional Functionality

• Inputs & Outputs• Processing• Availability• Resource Requirements



• New Service Specification– Interface Requirements

• User Interface– GUI, Command-line, API, etc.

• Hardware Interfaces• Communication Interfaces• Software Interfaces



• New Service Specification– Environment

• OS Compatibility• Prerequisites• Hardware Requirements• Storage Requirements

– Internal, External, Temporary

• Security Facilities



• New Service Specification– Performance Requirements

• Hours of Use• Number of Users• Benchmark Statistics• Security History



• New Service Specification– Budgetary

• Software Cost– Budgeted, Actual, Payment Source

• Hardware Costs– Budgeted, Actual, Payment Source

• Maintenance– Support, Service, Upgrades


Defining System Impact

• Estimate use– How many users?– How frequently?

• Estimate system burden– Time of average job processed (CPU)– Memory requirements– Disk requirements


Selecting a Package

• User input– If they pay, they say

• System intense software may require a separate platform

• Limited voice in selection

– If they plead, they heed• Typically an add-on package or new module

– May impact security or operational policies

• Maximum voice in selection



• New Service Selection– User Service Functional Requirements

• Required Functionality• Desired Functionality

– Requested Service or System• Functional Description

– User-Service Match• Requirements Met• Requirements Missed• Total Score





• New Service Selection– Comparable Services

• Description– Functional– Requirements

» OS, Hardware, Software, etc.

– System Availability• System Resources

– Min/Max/Mean– Time– Etc.



• New Service Selection– User-Service-System Match

• Requirements Met• Requirements Missed• Total Score

– User-Comparable Service-System Match• Requirements Met• Requirements Missed• Total Score




Construction

• Drawing the Blueprints– Preparation

• Read the documentation• Understand the Specifications

– Installation path• Plan it out on paper• Verify system resources

– Available disk space– Prerequisite software

• System impact & planning• Testing procedures

– Test the boundaries » no parachute needed


Open Source Administration

• Installation & Configuration– Auto

• RPM– Rpm –Uvh package.i386.rpm

» Install or upgrade

• Configuration scripts– ./configure; make; make install



• Installation & Configuration (cont)– Manual

• Determining dependencies• Modifications

– Configuration» Compile time options

– Make» Customizing to your system

• Troubleshooting– Knowledge– man: the UNIX savior– Knowing what to ask and where

Developer sites User forums News groups



• Management & Maintenance– Backups

• System• Data

– Monitoring & Evaluating• Updates & Upgrades

– Test Systems– Active Administration

• Patches• Advisories• System Use

– Logs & Monitors

– Backup Personnel Plan



• Open Source Management– Access to Updates, Fixes & Patches

• Mirror, Notification, etc.

– System Verification• System Changes (files, etc.)

– Tripwire

• Package Verification– Checksums, etc.

• Failure Monitoring– Syslog, etc.



• Open Source Management– Log Parsing

• Access, Activity, Failures, etc.

– House Cleaning• Removal of Unused Utilities

– System Audit• System Resource Usage

– Disk, CPU, Memory, etc.» Time & Process

• Accounts & Activity



• Open Source Management– SOPs – (Standard Operating Procedures)

• Routine Tasks• Installations• Upgrades• Etc.



• Open Source Management– Centralized Management

• Log Server(s)• JumpStart Server• Authentication





• Extension– Adding functionality– Extending the Open Source initiative


Question & Answer Session

• Open discussion


References

1. http://www.gnu.org/philosophy/drdobbs-letter.html2. http://www.techrepublic.com/

article.jhtml;jsessionid=XIEZAAVPZEYJOQD23WQCFEY?id=t01520010510eje20.htm&vf=dd&rcode=t015

3. http://www.opensource.org/advocacy/faq.html4. Merriam-Webster Dictionary: http://m-w.com/cgi-bin/dictionary5. The Risks of Closed Source Computing;

http://www.linux.org.uk/FEATURE/risk.html6. Look out Apache and IIS; here comes Xitami;

http://www.techrepublic.com/article.jhtml?id=r00220011127ern01.htm&src=search

7. http://www.suse.com/us/press/press_releases/archive01/ibm_suse.html8. http://setiathome.ssl.berkeley.edu/9. http://www.sendmail.org/10. http://www.courier-mta.org/11. http://www.qmail.org/top.html12. http://www.squid-cache.org/


Other References

• http://www.asynchrony.com/welcome.jsp

• http://www.wu-ftpd.org/

• http://www.centerforthepublicdomain.org/

• http://www.gnu.org/

• http://www.opensource.org/

• http://www.eeye.com

• http://www.foundstone.com

Documents

A Model for Open Source & System Administration Managing Open Source Software in a Production Environment SANS 2002 Orlando, FL April 2002 Presented by: