White PapersHP Open Source Consulting Services can help you implement the technology stack into your enterprise and service-oriented architecture environment. HP professionals work with you to build and integrate open source and commercial software across multiple operating system (OS) environments.
HP Open Source Support Services offer industry-leading technical support services for hardware and software stack components. HP provides access to software technical support experts and one-stop accountability through a single contract, invoice, and phone number.
HP Open Source Middleware Stacks WhitePaper:Security of Open Source Middleware StacksPrinted in the USHP Part Number: 599 1 7435Published: October 2006Edition: 1 .0Untitled Document Copyright 2006 Hewlett-Packard Development Company, L.P.Legal NoticeConfidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, CommercialComputer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government undervendor's standard commercial license.The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the expresswarranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HPshall not be liable for technical or editorial errors or omissions contained herein.AcknowledgmentsRED HAT READY Logo and RED HAT CERTIFIED PARTNER Logo are trademarks of Red Hat, Inc.Untitled DocumentTable of ContentsIntroduction..............................................................................................................................................5Executive Summary..............................................................................................................................5Intended Audience...............................................................................................................................5Scope and Purpose ..............................................................................................................................5White Paper Organization...............................................................................................................6HP Services..........................................................................................................................................6Defining Security.......................................................................................................................................7Computer Security Review.........................................................................................................................7Background.........................................................................................................................................7Areas of Concern..................................................................................................................................8The Security Policy...............................................................................................................................8Steps for Securing Computer Systems..................................................................................................10Essential Security.....................................................................................................................................11Known Versus Unknown Attacks ........................................................................................................11Keeping Systems Updated...................................................................................................................13The Vulnerability Life Cycle...........................................................................................................13Tracking Vulnerability...................................................................................................................15Making Configurations Secure.............................................................................................................16Addressing Configuration Weaknesses...........................................................................................17Automating Secure Configurations.................................................................................................19Additional Best Practices.....................................................................................................................20Use a Firewall...............................................................................................................................20Use Secure Communications..........................................................................................................21Use Layered Security.....................................................................................................................21Test Your System...........................................................................................................................22Never Assume the System Is Secure................................................................................................22Advanced Security...................................................................................................................................22Intrusion Management........................................................................................................................23Advanced Access Control....................................................................................................................23Access Control Background...........................................................................................................24Access Control Models..................................................................................................................24Linux Security Modules.................................................................................................................25SELinux........................................................................................................................................25AppArmor....................................................................................................................................25Comparing AppArmor with SELinux.............................................................................................25Monitoring and Forensic Tools.............................................................................................................26Conclusion ..............................................................................................................................................26Glossary..................................................................................................................................................26Table of Contents3Untitled Document4Untitled DocumentIntroductionExecutive SummaryDeployed Linux-based HP Open Source Middleware Stacks (OSMS) is an individual system composedof various components, configurations, and services. OSMS are a viable alternative to proprietary computersystems. When deployed, each system faces unique vulnerabilities and threats. Therefore, security cannotbe applied to every system in the same way. No single security solution applies to all systems. To achievean acceptable level of protection, you must understand your system and its environment.Security is not static so a secure solution today may not be secure tomorrow. Therefore, security is a processrather than a single component, device, or practice. This process includes performing a continual analysisof effectiveness, making appropriate adjustments, and balancing trade-offs within a particular system.This paper provides an overview of the security environment for OSMS in the system, network, andcomponents areas. In addition, concise descriptions of important security considerations are included toenable you to choose an appropriate security strategy for your environment.Intended AudienceThe intended audience for this document is all customers interested in learning about Linux securityspecific to OSMS.Scope and PurposeThis white paper is not a tutorial or a how-to document, and it does not describe how to secure OSMS.Rather, it provides a foundation for understanding the OSMS security environment and presents issuesand options related to securing OSMS. You must choose the correct set of solutions for a particular system.Each OSMS environment has a unique configuration, unique threats, and unique security goals. Therefore,each OSMS environment requires a unique security solution. Various open source tools and techniquesfor securing an OSMS environment are described in this paper and shown in Figure 1. In addition,background information for each topic is provided.Introduction5Untitled DocumentFigure 1 Security IssuesWhite Paper OrganizationInformation is organized in general technology topics, such as security background, essential securityinformation, and advanced security information. Additionally, each section contains links to bothintroductory and advanced material, when applicable.Examples that have direct application to securing OSMS are shown as follows:OpenSSL (http://www.openssl.org) provides OSMS with encrypted network connectionsand manages the eavesdropping risk for a secure Web transaction.HP ServicesHP Open Source Consulting Services can help you implement the technology stack into your enterpriseand service-oriented architecture environment. HP professionals work with you to build and integrateopen source and commercial software across multiple operating system (OS) environments.HP Open Source Support Services offer industry-leading technical support services for hardware andsoftware stack components. HP provides access to software technical support experts and one-stopaccountability through a single contract, invoice, and phone number.You also have access to software subscription networks from HP partners. HP support services are soldwith software subscription services for JBoss and the entire JBoss Enterprise Middleware Suite (JEMS).This enables you to access the JBoss Operations Network to obtain certified patches, updates, fixes, anddocumentation.To learn more about HP Open Source Consulting and Support Services, please contact your local HP salesrepresentative or visit HP at:http://www.hp.com/hps6Untitled DocumentDefiningSecurityYourfirstchallengeistounderstandwhatcomputersecuritymeans.Thisisimportantbecausesecurityisoftenmisunderstood.Oftenthetermsecurityisseenasanextensionofreliabilitybecauseinsecurecomputersinterruptyourdependencyuponcomputers.Obviously,systemsmustbesecuretobereliable,yettheterm secure isoftenusedincorrectlyasanabsolutemeasureofthisreliability,asifnothingcouldevergowrong.Security,likereliability,isnotsoblack-and-white.Computerreliabilityisaprobabilitymeasureofwhetherasystemwillfunctionasintended.Computersecurityisconcernedwithmanagingreliabilityinthepresenceofmalevolentinfluences.Asimpledefinitionofasecurecomputeris:asystemwhichdoesexactlywhatwewantittodoandnothingthatwedon'twantittodoevenwhensomeoneelsetriestomakeitbehavedifferently.1Ofcourse,abreachinsecuritycanrenderasystemunreliableandworseitcanleadtodataloss,informationtheft,andevenlossofacompany sreputation.Therefore,tobereliable,anOSMSdeploymentmustbemadesecure.Tounderstandhowtosecureacomputerrequiresanunderstandingwhatcanbeexpectedofaparticularsystem.Asystemscontextandcircumstancesmustbeexaminedtoassesswhetherasystemissecure.Therefore,theideathatasystemis secure ornotneedsanassociationwithaparticularsystem,anenvironment,andadegreeofacceptablerisk.Asdescribedinthiswhitepaper,thisexaminationisaformalprocessgovernedbytheSecurityPolicy.Securityexpectationsvaryaccordingtoasystem'scomponentsandthethreatsthesystemfaces.Securityrisksrepresentthedegreetowhichyoubelieveasystemisresistanttothreats,whileconsideringtheconsequencesifthesystemisnotresistant.Unacceptablyhighriskscanbetemperedbyadoptingsecuritymeasuresuntiltherisklevelisacceptable.Fortunately,theopensourcecommunityhasmanysecurity-relatedtools,whichreducerisks.Usingthesetools,Linuxsystemscanfitsecurelyandreliablyintomanydifferentenvironments.Eachsystem,theenvironmentinwhichitresides,andtheacceptablelevelofriskwillchangeovertime.Therefore,thesecurityofthesystemalsochangesandaprocessmustbeestablishedtomanagethisongoingchange.Oftentheweakestlinkinsecurityisprocessesthatdonotexist,arenotimplemented,orareevenignored.Guidelinesandbestpracticesdonotimprovesecurityunlesstheyareadoptedintoanongoing,managedsecuritypolicy.Eachtoolortechniquedescribedinthiswhitepaperaddressesdifferentsecurityissuesandprovidesadifferentsecuritylevel.EachisappropriatefordifferentOSMSconfigurations,threatenvironments,andsecuritygoals.Thiswhitepaperdescribesthesimplestandleastsecuremethodsfirstandproceedstothemostsecure,mostdifficulttoimplement,andmostdifficulttousemethods.Yourgoalistodeterminewhatmethodsareappropriateforyoursystem,andthenincorporatethemintoyourongoingsecuritymanagementpolicy.ComputerSecurityReviewThissectionincludesthefollowingtopics:" Background " AreasofConcern " TheSecurityPolicy " StepsforSecuringComputerSystems BackgroundThekeyelementofsecurityisknowledge.Beingawareofsecurityissuesandunderstandinghowtocurtailtheiraffectisparamount.Asecurityriskisthelikelihoodofadisruptionrelativetotheconsequencesofthedisruption.Asecuritythreatisanyeventthatinterfereswiththereliabilityofasystem,specificallywithinanyofthefourareasofinformationsecurity:confidentiality,integrity,availability,andaccountability.Thesedifferentareasareoftencomplexlyinterrelated.Thegoalofsecuringacomputersystemistoidentifyandreducesecurityrisks.AnOSMSismiddlewarethatexistsoveranOS,andbothlayersmustbesecurefortheentiresystemtobesecure.Therefore,to1. "Security."Wikipedia,TheFreeEncyclopedia.6Jul2006,10:55UTC.WikimediaFoundations,Inc.10Aug2004http://en.wikipedia.org/wiki/SecurityDefiningSecurity 7Untitled DocumentsecureanOSMSenvironment,youmustconsiderthethreatstowhichbothlayersmightbeexposed,considerwhatrisksthesethreatspose,andthendeterminewhichprocessesmightreducetheriskstoanacceptablelevel.AreasofConcernConfidentiality Concernscontrollingwhomayaccessparticularinformation,suchaslimitingwhichemployeesarepermittedtoviewconfidentialcorporateinformationorpreventinganeavesdropperfromrecordinganetworktransaction.Forexample,theOpenSSHsuiteprovidesanencryptedsecureshellthatenablessecureconnectionsbetweensystemseitherbyusersorbyautomatedsystems.Formoreinformation,seetheOpenSSHWebsiteat:http://www.openssh.orgNOTE: Theexamplespresentedthroughoutthiswhitepaperareintendedtoprovideoneofmanyoftheavailableoptions.Integrity Indicatesthelevelofassurancethatitemshavenotsuccumbedtotamperingandaltering,exceptbyusersandprocessesexplicitlygivenprivileges.Forexample,GnuPGprovidesdigitalsignaturecapabilitiesforitemssuchase-mailandfilestodetecttampering.Formoreinformation,seetheGnuPGWebsiteat:http://www.gnupg.orgAvailability Aimstoreducetherisksofunreliableaccesstoinformationandservices.Forexample,networkserversexperienceadenial-of-service(DoS)attackiftheirnetworkpathsarecongestedwithmalicioustraffic,andsuccessfulsystemintrusionallowstheattackertoshutdownservicesatwill.Oftenattackssendmalformedrequeststoaserviceforcingtheservicetohandletheminefficiently.Forexample,ModSecurityisanopensourceintrusiondetectionandpreventionenginethatexaminesHTTPrequestsbeforeasystemcanfullyexaminethem.Inthisway,ModSecuritycanfilteroutbadtrafficthatwouldotherwisedenyserviceavailabilityfromlegitimaterequests.Formoreinformation,seetheModSecurityWebsiteat:http://www.modsecurity.orgAccountability Concernsprovidingreliableidentificationofusersandagents.Accountabilityisassociatedwithnon-repudiation,authentication,andauthorization,anditfitsunderthebroadertopicofidentitymanagement.Forexample,connectionstoandfromadatabaseservermightrequireencryptedcommunicationchannelssincedatabasetablesshouldremainunalteredexceptbythoseusersandprocessesexplicitlygivenadministrationprivileges.Passwordsaloneareweakauthentication,buttheaddeduseofencryptedcredentialsonasmartcardprovidesstrongauthentication.OpenSSLprovidesOSMSwithencryptednetworkconnectionsandmanageseavesdroppingriskforasecureWebtransaction.Formoreinformation,seetheOpenSSLWebsiteat:http://www.openssl.orgThoughitisnotstrictlyasecuritytool,OpenLDAPcanbeusedtoimplementthebackendforthemanagementofuserinformation.Eachuserprovidesidentifyingcredentialstotheaccesscontrolsystem,andinreturn,thesystemgrantsprivilegesbasedonwhotheuserisorwhatworktheuserdoes.BothJBossandApachecanrelyuponOpenLDAPasadirectoryservicerepository,storinginformationaboutusersforaccesscontrol.http://www.openldap.orgUsingaload-balancingconfiguration,OSMSBlueprintscanbeusedtogainhigh-availabilitypropertiesthatalsoprovideresilienceagainstDoSattacks.Maliciousattacksinvolveallfourareasofconcerns.Assoonasamaliciousintrudergainscontrolofasystem,theintrudercanaffectanypartofthesystematwill.Datacanbeintentionallylost,corrupted,orshared.Intruderscanshutdownservices,andcanevencovertheirtracksinsystemlogs.Bystrengtheningasystem'sabilitytoresistattacks,youcanlowerawiderangeofsecurityrisks.TheSecurityPolicyComputersystemsareexpectedtobesecure,yetoftentheseexpectationsarenotstatedexplicitly.Securitybeginswithaformalstatementofexpectations,whichlogicallyoccursbeforetheimplementationofany8Untitled Documentsecuritymeasures.Thisformalstatement,calledasecuritypolicy,answersthefollowingquestionsaboutasystem:" Whatareattackerslikelytopursue,whatisofvalue,andwhatneedsprotection? Forexample,dataorcomputerresources" Whatthreatsarepresent,andhowlikelyisitthattheywilloccur? Forexample,automatedscripts,targetedattacks,ordisgruntledinsidersabotage" Whataretheconsequencesofasecuritybreach? Forexample,lossofreputation,lossofsensitivedata,orlossofresourcesAfterdevelopingthesecuritypolicy,asecurityauditshouldbeperformedtomeasuresecurityrisksandtoidentifyitemsofvaluethatareatriskasdefinedbythepolicy.Anauditreviewscheduleshouldbedefinedandexecutedonaregularandongoingbasis.Asecuritypseudo-formula,whichgeneratesameasureofsecurityriskforeachitem,isasfollows:(Threat Countermeasure) x Value Riskwhere: Threatisthepotentialofarealinterruptiontoasecurityconcern.Valueisanythingyoudonotwanttobeaffectedbytheinterruptionofasecurityconcern.Riskisthepotentialofasecuritybreachcombinedwiththedamageitwouldproduce.Countermeasuresareprocesses,tools,andconfigurationsthatmightreducethreats,thusloweringarisksoitisclosertoyoursecuritypolicyguidelines.Riskcanhavemuchmorecomplicatedrepresentationsthanindicatedbythesimplifiedsecuritypseudo-formula.However,thissimplifiedformulaallowsyoutocompareanitem srisksleveltothatoftherisklevelallowedbythesecuritypolicy.Figure2showstheitemsofinterestinthissimplifiedformula.Foragivenitemfacingathreatwithoutcountermeasurestoprotectit,ariskexistsonlyiftheitemisofvalue.Therefore,youdonotneedtoprotectunimportantitems.Theformuladoesnotmakesenseiftherearemorecountermeasuresinplacethantherearethreats,becausethentheriskisnegative.Thisisthecasefordecoysystems,whichcontainnovaluebutareusedasbaittostudyattacks.Figure2RiskMitigationProcessWhatdoessecuringOSMSmean?Youmustdefinewhattosecure,whatthreatsitneedstowithstand,andwhatsafeguardswillprovideprotectionfromthesethreats.DeterminingthatanOSMSenvironmentissecuremeanshavingconfidencethattheOSMSsystemwillnotsuccumbtoasecuritybreachinitsoperatingenvironment,norwillitintroduceunnecessarysecurityriskstothesystemthatcontainsit,asdefinedbyasecuritypolicy.Forexample,usingaJ2EEOSMSBlueprintonSLES9is secure becausedoingsomeetsmandateswithinthesecuritypolicyforprovidingsufficientprotectionfortheinformationitservesandthethreatenvironmentinwhichitresides.ThiswasachievedbyhardeningthehostOSandconfiguringtheblueprintsecurely.Inaddition,theJ2EEsystemresidesinaDMZ,tomitigateriskstoothersystemsassociatedwithopeningnecessaryportsinthefirewallforJ2EEservices.Formoreinformationregardingtheblueprintinthisexample,seeHPOpenSourceMiddlewareStacksBlueprint:J2EEApplicationServerBasedonHPProLiantandBladeSystemx86_64ServersandonNovellSUSELinuxEnterpriseServer9ServicePack3at:http://www.docs.hp.com/en/linuxsuse.html#Open%20Source%20Middleware%20Stacks%20%28OSMS%29ComputerSecurityReview 9Untitled DocumentSteps for Securing Computer SystemsAfter creating a security policy, you can begin the task of applying the policy. Perform the following stepson an ongoing basis to ensure the security policy is applied throughout the life of the systems.1.Identify:Determine the required security level of each computer system, component, or service based on theitem's importance (as specified in the security policy) and the degree of risk to which each item mightbe exposed in its deployed environment.2.Protect:Implement security measures to mitigate the risks identified in the first step. These security measuresadjust the risk to an acceptable level, as described in the security policy. Test these measures to ensurethey are operating as intended, and then adjust them as needed. Testing is particularly importantafter any changes to the system. Protection is not static, so the processes for securing a system changesover time. The goal is to uphold the security policy at all times.3.Detect:Ensure security policy breaches are detected by using tools and regular audits. Detecting a breachsoon after it occurs can limit the damage it causes.4.Respond:Use knowledge gained through the entire process to strengthen security implementation and mitigatesecurity policy breaches when then occur. Monitor changes to the threats a system might experienceby implementing additional countermeasures.Apply Best PracticesIn general, security practices should follow these well-known principles:"Keep it simple:Complicated systems provide more possibility for errors, which, in this context, means security risks.The need for simplicity touches most every aspect of security. The system design itself has the mostobvious need for simplicity because complexity relates to errors. However, a simple administrationtool, clear user instructions, and simple error messages are important too."Do not do it yourself :Contrary to the open source ideals, security is not a do-it-yourself project. Your newly created securityapplication has more potential for flaws than one that passes a far-reaching examination. Insist onan exhaustive review of any security design."Use well-known security techniques: Do not rely solely on clever hiding of important items, which is often referred to as "Securitythrough Obscurity". For example, when an application call requires authentication, do not hidethe password in a binary file or some other obscure location that you think is not obvious. The security of an algorithm should not depend on its secrecy. Relying on a hidden design forthe security of an application represents a security hole. You are assuming that only thedevelopment team knows the ways to exploit the algorithm, and that know one else will discoverwhat you know. For example, do not hide the house key under the doormat.10Untitled Document" Followtheprincipleofleastprivilege: Thisprincipleistodenyallprivileges,exceptthosethatareexplicitlyallowed.Inotherwords,denyaccesstousersandprocessesfirst,andthengrantprivilegesonacase-by-casebasisonlywhenneeded,inaccordancewiththesecuritypolicy. Servicesthatrununderrootprivilegeenableacompromisedprocesstohaveauthorityovertheentiresystem.Instead,createauserforeachprocessandassignownershipofonlytheresourceseachuserneeds. Donotforgettoaudittheaccesscontrolsperiodicallyandtorevokeprivilegeswhenneeded.Thesecuritypolicydefinesascheduleofauditrecordreviewandwhentotakeaction.OnewaytosecureanApacheserver,istoavoidusingtherootaccount.Rather,youshouldcreateanewuser(oftennamedwww-data)accountandensurethatithasonlyminimalaccesstothesystemanditsfunctions.Permitaccesstothewww-dataaccounttoonlyuserswithagenuineneedandtoasfewusersaspossible.ThenrunApacheusingwww-dataandifitiscompromised,theattackerwillnothaverootprivileges." Securitytoolsdonotmeansecurity: Havingtoolsdoesnotensuresecurity.Whatisimportantiswhatyoubuildandconfigurewiththetools,whichmightormightnotbesecure. Toolsmightimplysecurity.However,improperlyconfiguredtoolsoralertsthatgounnoticedimplyafalsesenseofsecurity,whichisworsethannosecurityatall.DonotassumethatusingOpenSSLautomaticallysecuresyourcommunications.UsingOpenSSLandfailingtoconfigureachainoftrustfortheservercertificatesleavesasecurityhole.Thisholeallowsanattackertolaunchman-in-the-middleattackswiththesameresultasiftheconnectionwasnotusingOpenSSL.Additionally,OpenSSLprotectsonlytheconnectionbetweencomputers;theinformationstoredonthecomputersisstillsusceptibletoattack." Makeituser-friendly:Balanceboththeuseandthesecurityofasystem.Understandably,securityoftenseemstoimpedeusabilityandusersdonotappreciateobtrusivesecurityimplementations.Elegantlyimplementedsecuritymeasuresavoidhinderingusers,whilemaintainingyoursecuritypolicy." Neverbelieveyouarefinished:Securityisanever-changingdomain.Whatyouconsidersecuretodaymightbeinsecuretomorrow.Adviceinsecuritypaperssuchasthispaper,becomesoutdatedwiththereleaseofnewcomponentversionsornewattackvectors.Reliablesecurityisaprocessthatrequiresconstantvigilance.Establishasetofpoliciesandprocedurestomanagesecurityneedsoverthelifeofthesystem.EssentialSecurityThissectionincludesthefollowingtopics:" KnownVersusUnknownAttacks " KeepingSystemsUpdated " MakingConfigurationsSecure " AdditionalBestPractices KnownVersusUnknownAttacksRememberthatsecurityisreallyameasureofacceptablerisk.Therefore,onlyasecuritypolicycandefinewhatissecure.Keepthispointinmindwhenyouarecontemplatinghowtofixasecurityflawinasoftwarepackagebyimplementingasecurityfix.Also,rememberthattheterms secure and notsecure pertaintothesoftwarepackagesthatyouareconcernedwithbecauseofyoursecuritypolicy.Sometimesaparticularsecurityissueisnotrelevanttoasystembasedonthedefinitionofriskinthesecuritypolicygoverningthesystem.EssentialSecurity 11Untitled DocumentIn view of this, secure software contains no risks, as defined by your policy, and it contains no issues thatare exploitable. Therefore, truly secure software does not exist, because it is not possible to prove anysoftware is void of flaw. You must always assume software contains undiscovered security issues.Proprietary and open source code are no different in this respect. This statement might appear rather bold;however, this is a perspective you must realize when securing computer systems.Remember that even the highest quality software contains a small percentage of flaws. Software engineeringand quality assurance principles attempt to minimize these flaws. All security flaws are considered bugs,but the reverse is not true. When a bug has exploits, which an attacker can intentionally manipulate, thebug becomes a security flaw. When flaws exist in certain circumstances, such as a component runningwith a privilege mode, the flaw can become a security vulnerability, which attackers intentionallyexploit.Figure 3 (page 12) shows security threats reported to the United States Computer EmergencyReadiness Team (US CERT or CERT). For more information regarding CERT, see the Web site at:http://www.us-cert.govFigure 3 CERT VulnerabilityTotal vulnerabilities reported 1995 2005. For 2006, data for only the first two quarters was available, sothe total is an estimate.The discovery of exploitable flaws periodically makes systems insecure. To return your system to a securestate, you apply a security patch, which fixes the software flaw and closes the exploitable vulnerability.Therefore, keeping a system up to date with the most recent and secure versions is the means by whichyou keep security lapses to a minimum.The widespread use of automated attack tools and attacks against Internet-connected systems have becomeso commonplace that CERT discontinued counting the number of incidents reported. In Figure 4, thedashed line is only an estimation of incident count.12Untitled DocumentFigure4IncidentsPerYearAlso,thereareotherexploitsthatarenotyetwidespreadorwellknown,butareequallypotent.Forexample,vigilantpatchingdoesnotpreventazerodayattack.Theseexploitsaretoonew,andapatchdoesnotexisttofixtheflawedsoftwaretheyexploit.Similarly,othersecuritytechniquesthatrelyonthepriorknowledgeofvulnerabilitiesandexploitsignaturescannotprotectasystemfromzerodayattacks.Signature-basedintrusiondetectors,firewalls,andvirusdetectiontoolscannotdetectattacksthathaveyettobedefined.KeepingSystemsUpdatedAllsoftwarecomponentsundergoacyclicreturntoaninsecurestateduetothediscoveryofnewsoftwarevulnerabilities.Surprisingly,themajorityofsystemsthathavesuccumbedtointrudersdosobecauseofaknownvulnerabilityforwhichapatchisreadilyavailable.2Therefore,keepingasystemuptodatewiththemost-recentsecuritypatchesisparamountforreducingexposuretoknownvulnerabilities.Patchmanagementisameansforreducingthelargestfactorofintrusionexposure.Thevigilantandtimelyapplicationofsecuritypatchesisthemostimportantitemonasecuritychecklist.Thebattlebetweensoftwaredevelopersandsoftwarecrackersisongoing.Anexploitrepresentsamomentofopportunityforattackerstopenetrateasystembeforepatchesareappliedthatreturnthesystemtoasecurestate.Softwarecrackersattempttogainadvantagebyfindingandexploitingsecurityholes,whilesoftwaredevelopersendeavortoclosetheholes.Thispatternrepeatsintheexploitlifecycle,soapplyingtimelysecurityupdatesisalwayscritical.TheVulnerabilityLifeCycleAfteravulnerabilityannouncement,aflawislikelytobecomeacrackingtarget.Often,inanattempttodefusethisinevitability,avulnerabilityannouncementisdelayedinordertocoincidewiththereleaseofapatchtoreducethetimeforanexploittobedeveloped.Thispracticeproducesafalsesenseofsecurity,becausetheactualstartofthevulnerabilitylifecyclecanbeginlongbeforetheannouncement.Thediscoveryofsecurityissuesoccursinmanyways.Intheworstcase,crackersdiscoverthevulnerabilityratherthansecurityexperts,sosystemsbecomecompromisedevenbeforeworktofixthevulnerabilitybegins.Inthebestcase,knowledgeofthevulnerabilityisknownonlytothesecurityresearcherandthedeveloper.Thedeveloperdoesnotdivulgetheexistenceofthevulnerabilitytopreventcrackersfromexploitingituntilafixisavailable.Meanwhile,thedeveloperquicklydevelopsandthoroughlytestsapatch.Unfortunately,whentheannouncementofavulnerabilitycoincideswiththereleaseofthepatch,anewthreatarises.Crackersareadeptatreverse-engineeringpatchesandproducingexploitsinashort2. J.Howard,AnAnalysisOfSecurityIncidentsOnTheInternet:1989 1995.PhDthesis,Carnegie-MellonUniversity,April1997.EssentialSecurity 13Untitled Documentamount of time. This period is continually shrinking, with time from the announcement to the time ofdiscovering an exploit typically being less than one day , as shown in Figure 5. This grants crackers theluxury of not searching for vulnerabilities themselves; they can rely on the computer security infrastructureto inform them of the best targets.The following three figures represent the vulnerability lifecycle, which is a depiction of the risks a singlesystem faces over time due to a single vulnerability. The goal of security is to reduce the amount of exposuretime a system experiences a risk, and to reduce the degree of exposed risk. Figure 5 represents the systemrisks over time for an unmitigated system, one that has not been hardened or had security patches promptlyapplied. Figure 6 represents the reduction of system exposure time due to the prompt application ofsecurity patches. Figure 7 represents the reduction of system risk from carefully hardening the systemconfigurationFigure 5 Threat Risks to Unmitigated SystemFigure 6 Threat Risks to Timely Patched System14Untitled DocumentFigure 7 Threat Risk to Hardened SystemIt is unwise to assume that there is plenty of time to deploy security patches after they are available. Thevulnerability life cycle can be well underway and unpatched systems are extremely vulnerable, so youshould always apply security patches immediately.Unfortunately, significant numbers of systems remain unpatched after a patch is available. The failure toapply patches in a timely manner unnecessarily extends the window of opportunity for attackers to exploitvulnerabilities.Patching otherwise reliable systems represents a degree of risk. Introducing new software through a patchrepresents an unknown effect to the reliability of computer systems. This risk should be weighed againstthe security risk represented by the unpatched software. Testing for undesirable side effects reduces therisk of patch side effects and should be mandatory for any critical systems. However, timing is also a factorbecause the delay between vulnerability disclosure and patch application increases security risk.Tracking VulnerabilityUnlike proprietary software produced by a single entity, cooperating entities manage open source softwaredevelopment. This allows the open source community to be agile during the development process becauseeach package developer can work independently. However, there is no omnipotent overseer ensuring theproper management of security processes.Knowing whether a particular system, component, or library is vulnerable is critical in determining thecurrent risks a system faces. The downside of the open source independent infrastructure is the lack ofeasy management of software vulnerabilities. Though there are various agencies that track vulnerabilities,it is problematic to determine definitively if an individual system is vulnerable at any given moment.For example, a search for a component by package name and version produces naming conflicts. TheCERT database attempts to correct this issue. However, the latency between the first report of a vulnerabilityand the appearance in this database poses significant exposure to new exploits, such as zero day attacks.The open source development process is observable, so one solution available to system managers is tomonitor the developer bulletin boards for critical system components and track vulnerabilities as theyflow through the layers of open source organizations. Typically, vulnerabilities begin with an initial bugreport submitted to the package maintainer, who confirms the submission, produces a security vulnerabilityannouncement, creates a patch, and adds it to the current stable stream. Linux distributions then applythis fix to the OS packages in their distribution and make their own announcement.Waiting for this patch announcement can leave a system vulnerable for an unnecessary period. Learningof a vulnerability as quickly as possible enables the implementation of other countermeasures. For example,Essential Security15Untitled Documentvulnerable components or systems could be confined so they cannot access sensitive information or affectother computers.Timely vulnerability information is critical. To track important security issues related to OSMScomponents, subscribe to any security announcement mailing lists that may be available. Thefollowing are a few examples for you to consider:Red Hat https://www.redhat.com/mailman/listinfo/enterprise-watch-listSuSE http://www.suse.com/us/private/support/online_help/mailinglists/Apache http://httpd.apache.org/lists.html#http-announceSystems run various versions of software, and distributions freeze the development stream for a givendistribution version. Unfortunately, a fix made at the beginning of the development stream might not becompatible with all downstream versions of the vulnerable package. The fix might need to be backportedfor earlier release versions. Different members of the community, from the package maintainer, todistributions, to even members of the open source community at large might perform backporting torelease patches and patched binaries. This process can add confusion when you are trying to identify thepatches applied to a given binary version or determine a version's current vulnerability status. This situationprovides more impetus for tracking vulnerabilities in process instead of waiting for a patch alert.Making Configurations SecureA system must be prepared even for previously unknown attacks. Security hardening, confinement,resource limitation, and other techniques protect systems from these unknown vulnerabilities. The followingsections describe the means by which you can minimize the risk a system faces from unknown attacks.The second leading cause of system intrusion is misconfiguration. The initial installation of the system soperating system and components contain many defaults, such as account names, passwords, leftoverconfiguration scripts, and open file permissions, among other things. These loose ends represent a serioussecurity risk. You must perform further configuration to secure the system. Unfortunately, the leftoverdefaults often remain for the life of the system and, because these defaults are common knowledge, theyprovide an easy attack point for malicious intruders. The process of securely configuring a system is calledhardening. Hardening is so effective, it might even secure systems that host vulnerable software.The best way to securely configure computer systems is to follow the guidance of experts in the securitycommunity. One source of expert information is CERT, which provides a good overview of properconfigurations. After you understand the scope of the task, you apply specific security configurations toeach system. The Linux distributions and package maintenance security documentation provide detailsabout hardening.Enterprise-grade open source components have security configuration guidelines within theiradministration documents. Following these recommendations is paramount for securing eachcomponent. For more information, see the following documents and Web page:Red Hat Enterprise Linux 4 Security Guide:http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/Chapter 8. Security on JBoss of The JBoss 4 Application Server Guide:http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch8.chapter.html 5.7. General Security Issues section of theMySQL 5.0 Reference Manual:http://dev.mysql.com/doc/refman/5.0/en/security.htmlThe Internet is rife with active attacks, so systems deployed without security configurations quicklysuccumb to attack. Therefore, your security policy should require the secure configuration of all systemsbefore deployment to ensure that systems are not compromised while they await hardening.Unfortunately, secure configuration is often done incompletely, done incorrectly, not maintained, oravoided altogether. Deployed systems often have components that are accessible by default passwords,unneeded services often continue to operate and respond to external network prompts, and an entiresystem can be vulnerable through the breach of only one component.16Untitled DocumentAddressing Configuration WeaknessesRegardless of which operating system or components might be present, your system s security dependson the state of its deployed configuration. A misconfigured system can undermine all other securitydesigns.The following is a list of configuration best practices. Following these essential practices can help youavoid many common security pitfalls in newly installed systems.Password management tasksDo not retain default passwords for any component or account. Searchfor and eliminate default account passwords.""Use the following Web search prove to yourself that defaultpasswords are common knowledge and easily exploitable:http://www.google.com/search?q=default+passwordThe mysql_install_db executable completes a MySQL installation, which initializesaccounts with the username root and gives them superuser privileges. These accountsstart off with empty passwords, and if the passwords are not changed, connections usingthe root account do not require passwords and yet possess all privileges.For more information, see the MySQL Web site at:http://www.mysql.com"Require strong passwords to deter a brute force attackPAM modules can aid the enforcement of password policies bychecking for password strength. For more information, see theLinux-PAM Web page at:http://www.kernel.org/pub/linux/libs/pam"Expire old passwords on a regular schedule.Passwords that gain access to critical systems should age the quickest.The more critical the item, the less time a password should be used."Audit your machines to ensure compliance with the password policy.Account management tasksLimit the number of failed login attempts to deter brute force attacks.Given enough time and if the passwords are weak, brute force attackscan bypass even the strong encryption of SSH. To prevent this, limit"login attempts with PAM or by component configurations such asthose found in OpenSSH."Limit access of privileged accounts from remote locations.For instance, the root account should not permit remote logins.Limiting remote logins can curtail privilege escalation of remoteattacks."Enable firewall rules to limit where remote logins can occur.By allowing logins only from the local subnet and by using a virtualprivate network (VPN), the system is protected from login attemptsby unknown network addresses."Use the principle of least privilege when assigning user and processrights. Remember this principle when managing user accounts andgive users just enough permission to get their job done. Use the sudo account and use it instead of root account logins,disabling the root user.Essential Security17Untitled Document" Prohibit shared accounts and generic account names, which defeatnon-repudiation. Lost knowledge of exactly who is using an account preventsaccountability from being a deterrent. Accounts such as tester, guest, and admin defeatnon-repudiation, and make user account names easy to guess."Log failed login attempts.Auditing the logs alerts you to password-guessing attack activity."Consider using certificate-based authentication.This type of authentication operates just like passwords and providesstronger security through encryption.Configuration tasksActively clean up user accounts.Remove accounts that are dormant or belong to ex-employees andthose that do not belong to known users.""Do not allow high-risk services to run in privileged mode.A server might need considerable privileges, but it does not need torun as root. By creating a special account for exposed servers, youlimits the damage an intruder can accomplish by compromising theexposed service.The Apache Web server needs access to many potentially vulnerable modules, CGIscripts, and Web applications. This need establishes Apache as a target of attackers.Therefore, you should not run the Apache process with the root account or else asuccessful attacker can also gain root privilege. Instead, run Apache with the www-dataaccount and give this account ownership of the minimum resources Apache requires tooperate. Put simply, it is better for an intruder have control of the www-data accountthan to have control of the root account."Deter fingerprinting, which is the remote identification of systems.Do not let network-available services respond by giving awayinformation that can identify them in any way. This includes theirversion, name, or other information.Turn off, or otherwise prevent, any error or debugging messagesfrom being visible remotely.The JBoss application server can post errors to the Web interface. Although this mightbe helpful for debugging purposes, it also gives attackers a view of the inner workingsof the JBoss server and provides sensitive information, such as version, build numbers,and error messages that can help guide an attack.For more information, see the JBoss Web site at:http://www.jboss.org"When possible, change the default network ports for services.You cannot change ports for services that require the use of a standardport. Although, if you have to connect remotely, try to use SSH to anunexpected port of your own choosing, such as 10022 instead of toport 22. Port scanners might not correctly detect the running serviceon nonstandard ports, especially if the service has been limited tosuppress fingerprinting information. This technique can deterattackers, especially automatic scanning engines that expect serviceson standard ports, by adding one more layer of security."Remove risky network services (Telnet, RSH, NFS, FTP, and others).Some services are notoriously insecure due to repeated flaws. Otherservices were designed under the assumption that they would be18Untitled Documentused in a trusted network environment. In either case, remove themand use secure equivalents: SSH, SCP, SFS, and SFTP."Remove all unneeded network services, which are services that arenot explicitly used by the system. Also remove sub-componentservices that a particular configuration does not use.If services are needed only occasionally, you should stop them andprevent them from restarting upon system boot. Alternatively, usefirewall rules to manage network access. For example, allow Sambato accept connections from the local network and not from outsidethe firewall."Eliminate unneeded packages.On deployed systems, remove compilers and tool chain libraries. Thegoal is to eliminate any tools that an unwelcome adversary can useagainst you. By removing the extraneous packages, you might findthat your normal set of tools is no longer available for debugging anddiagnostics. This can be bothersome, but remember that leaving onlythe required components on a deployed server is a form of minimalprivilege enforcement. Give the servers only what they need and youmight give attackers less of what they need.Automating Secure ConfigurationsKeeping track of all the critical configurations is complex. Increasing this complexity is the fact that asystem s configuration needs change over time. For example, secure configurations often turn up as adefault in future package releases, so systems no longer need special configurations during deployment.Conversely, new releases offer new functionality, and might require new security modifications. Becauseof these changing requirements, using a configuration tool makes sense. Give the important task of keepingconfigurations current to professionals in the security field.The Bastille Linux open source project is ideal for securely configuring a system. Bastille is an interactivescript, which examines the configuration of a system and suggests hardening changes. Two importantgoals of Bastille are:"Provide educational information regarding safe security practices through a hands-on interactivescript."Provide a means to secure a system through systematic configurations.Bastille is also customizable for specific systems. You can harden an OSMS environment to match a defaultconfiguration file, or you can use an extension of the Bastille defaults for a specific system. Bastille canconfigure several systems in the same manner, and it can perform security regression testing after makingchanges to a system.Bastille guides you through the hardening process by explaining each security issue, allowing you tochoose whether to implement a hardening configuration, explaining the consequences of each choice, andsuggesting preferred choices. Bastille detects default passwords, enables the implementation of the principleof least privilege, removes suid programs, and provides a local system firewall, and it also mitigatesmany other security issues.Bastille adheres to many security best practices. Properly configuring a system is complicated and requiresa considerable amount of knowledge. Using Bastille simplifies this task and provides access to acollaboration of effort from others in the security field. Systems configured using Bastille benefit by notbeing overly complicated and by conforming to a well-formed configuration script that has been reviewedby others in the security field.For more details, see the Bastille Linux Web site at:http://www.bastille-linux.orgEssential Security19Untitled DocumentAdditional Best PracticesThis section includes the following topics:" Use a Firewall " Use Secure Communications " Use Layered Security (page 21)" Never Assume the System Is Secure Use a FirewallFirewalls can explicitly limit network traffic using a variety of filtering methods. Often firewalls manageconnections by port and network address, and only those connections explicitly granted access (througha white list) may pass through the firewall. Typically, firewalls limit inbound connections; however,filtering outbound connections is also possible. Outbound (known as an egress firewall) protection isuseful for preventing unauthorized connections from unknown local processes (for example, Trojanprograms and other malware) or connections to risky external networks. Firewall must be placed betweenthe network and the systems that need protection.Hardware firewalls are located on the network and have the main task of filtering traffic for a subnet.Software firewalls are processes that reside on local machines and filter the connections to the local services.Software firewalls are vulnerable to attacks originating from the local machine. If an intruder gains access,the intruder might be able to subvert the firewall. Hardware firewalls are isolated and limited to the soletask of filtering, so are less likely to be compromised in this manner.Software firewalls can even reside on local systems, for example, Bastille and Red Hat Linux firewalls canwork in conjunction with firewalls positioned at the network gateway.Network topologies that employ a demilitarized zone (DMZ) approach (see Figure 8) have layers offirewalls that offer different levels of protection and availability to systems as needed. This approach canlimit the damage done by a successful attack by isolating the exposure to other systems.Figure 8 DMZ ApproachThe DMZ separates computers that face external hazards from other systems.Remember, a secure system should not have access to unneeded services. This might mean that a serviceaccessed only on the local network should have firewall rules denying access from connections that arenot from the local network. If the service is not required at all, remove it instead of blocking access to it.Firewalls are just one defensive measure within a layered security approach. Do not rely solely on perimeter20Untitled Documentprotectionfromafirewall,becauseyoushouldneverrelyonanyonedefenseincasethefirewalliscompromised.Trojanscanthwartfirewallsecurityandattackfromwithintheperimeterdefenses.Linuxisanidealsystemwithwhichtocreateafirewall.Usingnetworkingtools,suchasiptables,anyconfiguredLinuxmachineisafirewallinitsownright.However,itisbestnottodesignandconfiguresecurityalone,becauseanyoversightleavesasystemvulnerable.Firewallprojectsareactiveintheopensourcecommunity.OnefirewallprojectdesignedfornetworkdeploymentistheSmoothWallproject,whichisahardenedminimalLinuxdistributionexpresslyforuseasastandalonefirewall.SmoothWallholdsapositioninthenetworkreplacingthegatewayrouterandperformsmanyusefultasksinadditiontofirewalling,suchasNAT,DHCP,logging,andevenintrusiondetection.Anadditionalmeansofcontaininganintruderthroughfirewallprotectionistonotrelysolelyonthegatewayfirewalltopreventallattacks.Thisisdonebyenablingfirewallrulesonlocalsystemsthatarebehindthegatewayprovidesanadditionallayerofprotection.Forthispurpose,theBastilleprojectprovidesthemeanstofilteraccesstoservicesonindividualmachines.Forinstance,allconnectionstoaMySQLdatabasecanbelimitedexclusivelytothoseoriginatingfromthelocalApacheprocess,subvertingremoteMySQLattackswhileenablingdatabaseservices.UseSecureCommunicationsCryptographicallysecurecommunicationprovidesanyorallofthefollowingservices:theconfidentialityofnetwork-transmitteddata,integrityofthecontents,andidentityofsendersorreceivers.Theseservicesdonotrequireconcurrentuse,sotheyshouldbedeployedasneeded.TheuseofSSHisoftenmistakenlybelievedtobesufficientforachievingasecuresystem.Remember,aparticulartool(evenawell-knownone)doesnotcreateasecuresystem.Forinstance,justbecauseyounoticethatyouareconnectingtoyourbankacrossanencryptedconnectiondoesnotmeanthatyourpersonaldataisnotatrisk.Itmightbetruethatthedatacannotbediscoveredbylisteningtotheconnection,butthedataisnotprotectedifsomeoneplacedakey-loggeronthecomputeryouareusingoryouare securely connectingtoaphishingWebsite.SSHdoesnotpreventtheclientfrombeingattackedbytheserveritconnectstoorviceversa.Sometimes,securingtransmittedinformationentailsensuringthattheinformationcannotsuccumbtoeavesdroppingattacks.Alternatively,theauthenticityofentitiesmightberequiredtoensuresecurityandtheintegrityoftransmittedinformationmightneedverification.Allofthesehavecryptographicsolutions,suchasencryptedtransmissions,authenticationsignatures,andcontenthashes.ToensurethesecurityofcommunicationwithaJBossapplicationserver,youmustimplementpoint-to-pointencryptionofmessages.SuchmethodstypicallyusetheSecureSocketLayer(SSL).OpenSSLisanopensourceprojectthatimplementsSSL.ConfiguringJBosswithOpenSSLforsecuremessagetransactions,suchasthoseusedinshoppingcartapplications,isstraightforward.However,donotforgettoproperlyintegrateaPublicKeyInfrastructure(PKI)systembecausewithoutverifyingcertificatessystemsarestillvulnerabletoman-in-the-middleattacks.Securingtransmittedinformationmightalsoinvolvetheuseofsecurecredentialsandpublicorprivatekeymanagementtechniques.Beawarethatencryptionreliesgreatlyonproperkeymanagement.Usingencryptedkeyswithoutacertificationauthority(CA)isasecurityrisk.Usingencryptedkeysissimilartousingpasswordsbecauseitrestrictsaccesstoonlythosewhopossessthekeys.Encryptedkeysmustbegeneratedcarefullytoensuretheyarestrong,andtheymustbecarefullyprotected.Keysareusedinmanyareasofsecurity,includingtheconfirmationofsystemanduseridentityduringtrustedtransactions,lockingandunlockingfilesforsecuretransfer,andprovidingpassword-likecredentials.AvalidCA,trustedbyallagentsinatransaction,mustrecognizethekeys.UseLayeredSecurityUsingvarioustechniquesinacoordinatedeffort,oftencalledsecurity-in-depth,createsthemostsecuresystems.Neverdependononelayerofsecurity;ifasystemhasonlyonelayerofsecurityandthatlayersuccumbstopenetration,theentiresystemisvulnerabletothesecuritybreach.Inalayeredapproach,ifonelayerfails,additionallayershavetheopportunitytocontaintheattack.Thelayerscanaugmenteachother,blanketingdifferentweaknesses.AlayeredapproachcanslowdownanEssentialSecurity 21Untitled Documentattacker, and might provide enough time for the intrusion to be detected, or the multiple layers mightprovide enough protection that the system is difficult to breach.The following is an example Apache setup that has a layered security defense:" Require authentication to administer the host system, and provide non-repudiation andan audit trail." Ensure that the Apache process does not run under root and also does not run using thesame account that is used to administer Apache." Use HTTPS for remote administration and commercial transactions, to guard againstman-in-the-middle attacks through an encrypted communication protocol." Use a local firewall filter, which limits open ports and the set of IP addresses allowed fora connection." Do not display information about the serving protocol or platform to clients to avoidproviding information for an attack vector." Refuse client connections after several unsuccessful logins to limit brute force attacks." Configure the Apache server within a chroot jail or run the www-data account to limitbreaches.Test Your SystemIt is tempting to believe that after all your configuration efforts, you have successfully created a securesystem. However, the true test of whether your system is secure is when a hacker attempts to penetrateyour carefully deployed defenses. You should try to break into the system and have someone who doesnot know the system do so, to simulate what an attacker might do to penetrate your defenses.There are several open source tools to help you simulate hacker attacks. Two scanning tools effective indetermining how robust your security implementation is are Nessus and Nmap. The Nessus tool uses alibrary of known exploit attack vectors to determine if a system is vulnerable to any of them. The librarymust be updated with new exploit vectors as soon as they are discovered, and it must be used periodicallyto ensure that systems continues to be secure.The Nmap tool uses raw IP packets to determine available hosts on the network, what services (applicationname and version) those hosts are offering, what operating systems versions they are running, what typeof packet filters and firewalls are in use, and other information.3The problem with using scanning tools is that they can detect only known vulnerabilities. Exploits threatena system for its life cycle, but unfortunately scanners cannot detect vulnerabilities that are not recognized.Therefore, although scanners are effective tools, other layers of security are required to ensure systemsare less susceptible to unrecognized, yet real, vulnerabilities. For example, you could place exposed servicesin chroot jails and limit the privilege of their processes, which mitigates the risk of exposure to the restof the system if they are compromised.For more information regarding Nessus and Nmap, see the following Web sites:http://www.nessus.orghttp://www.insecure.org/nmapNever Assume the System Is SecureSecurity is time sensitive. A system that appears to be secure can suddenly become insecure. This changecan occur when change occurs in the Security Policy, a new package is installed, there are personnelchanges, or configuration modifications are made. Additionally, a system that has no known vulnerabilitiescan suddenly become susceptible to attacks that use new methods to exploit a previously unknownvulnerability.Security requires constant vigilance and maintenance. New vulnerabilities appear suddenly and thesystems they affect must obtain patches or be removed from a risky environment at a moment's notice.Knowing the moment at which a system becomes vulnerable and having a predefined plan to deal withcontingencies is critical.Advanced SecurityThe previous sections describe a basis for configuring and maintaining secure systems. Configuringinstalled components in a secure manner, minimizing their exposure to network risks, and maintainingpatches reduces the risks components face. The initial security practices described previously do not3. The nmap manpage is open source and licensed under the GNU General Public License, Version 2. Seehttp://insecure.org/nmap/man/22Untitled Documentrequire tools outside of the main middleware stack, although tools such as Bastille help you to do the jobright.This section describes a set of security tools and techniques that are secondary to the primary purpose ofa middleware stack. These tools are extraneous to the installed components, yet they operate in supportof the primary components by bolstering their reliability through security.This section includes the following topics:" Intrusion Management " Advanced Access Control " Monitoring and Forensic Tools Intrusion ManagementIntrusion management attempts to mitigate security breaches. To mitigate a breach, you must detectunauthorized system access as quickly as possible. Intrusion begins with a weakness. Theoretically, ifthere is no weakness, there can be no breaches. Unfortunately, weaknesses do exist and even apparentlysecure systems might contain unnoticed weaknesses that remain even after the most diligent audits.Moreover, new software, new hardware, or new personnel can introduce additional issues.The following are just some of the methods for mitigating an attack:"limiting a breach by isolating services and assets"encrypting the assets so they are unusable"detecting the intrusion as it happens"responding quickly"closing the breachThe section Essential Security (page 11) described a bastion host, which is an isolated, fortified systemthat provides services to untrusted clients and is, therefore, exposed to risk of attack. Such a system is bestisolated in a DMZ to reduce threats to other systems and to protect the other systems in case the bastionhost is compromised. Using chroot, a standard command line tool, can provide a similar environment,only this time the isolation is within a system. The files available to processes are limited by isolating riskyprocesses into what are known as chroot jails. Placing processes in a self-contained environment limitsan intruder's access to a minimal subset of the system internals. In this way, the principle of least privilegeis enforced.Protecting the contents of sensitive data stores is essential. Encryption can reduce the risk of exposingsensitive data. Tools such as GnuPG can encrypt files that need protection. A secure design of the encryptionprocess, especially when working with the encryption keys, is essential. The resulting data store can containinformation that is unreadable except by clients who possess the encryption key.The goal of intrusion detection is to detect the signatures of known attacks. Unfortunately, intrusiondetection is ineffective against previously unknown attacks. Because intrusion detection cannot detectunknown attacks, it provides the same level of security as an up-to-date system. However, when youcannot patch a system due to patch conflicts, delays in testing the patch, or patch unavailability, an intrusiondetection system can serve as a stopgap. However, from a security standpoint, it is better to patchvulnerabilities than to try to block their exploits. Several well-known intrusion detection projects existwithin the open source community. One such project is Snort, a signature-based intrusion detection system.For more information, see the Snort Web site at:http://www.snort.orgAdvanced Access ControlThis section includes the following topics:" Access Control Background " Access Control Models " Linux Security Modules " SELinux " AppArmor " Comparing AppArmor with SELinux Advanced Security23Untitled DocumentAccessControlBackgroundYoucansecureonlywhatyoucancontrol.Thisseemsobvious,yettheUNIXfilesystemdesign(hereaftercalledPOSIX),uponwhichLinuxisbased,securesallfilesinthesystematthediscretionofthefileowner.Nosystemorpolicycontrolexistsoverauser'sabilitytochangepermissionsforfilestheuserowns.Userscanevengrantownershippermissionstotheirownfiles;thereafter,theythemselvesdonotretaincontrolofthefile.Allowinguserstosetfilepermissionsinthiswayistermeddiscretionaryaccesscontrol(DAC).ThePOSIXpermissionsystemalsoprovidesultimateprivilegetotherootusertoenabletheadministrationofallsystemneeds.However,thepresenceoftherootuserpresentsaparadox,becausefilesmightexisttowhichuserswithrootaccountsshouldnothaveprivilege.Forexample,thesystemadministratorshouldnotbeabletoreadpersonnelfilescontainingemployeemedicalinformation.Theabilityofasystemtoenforceaccesscontrolpoliciesoneveryuser,includingroot,andtodisallowusersfromchangingpermissionsiscalledmandatoryaccesscontrol(MAC).POSIXusesaccesscontrollists(ACLs)todeterminewhichusersandprocesscanaccessitemsonthesystem.Theselistshavelimitedabilitytoenablefine-grainedpermissionschemasandadvancedaccesscontrolmodels.Therearetwotypesoflists:minimalACLs,whichhavethreeentriesandarethemostfamiliar,andextendedACLs,whichhavemorethanthreeentries,provideaslightlyfiner-grainedcontrol,andaremorecomplextoadminister.AccessControlModelsTherearemanyaccesscontrolmodelsthatarenotdescribedinthiswhitepaper.ManyofthesemodelsimplementaMulti-Level-Securitymodel(MLS),whichisaMAC-basedmodelwithamilitary-likesecurityandconfidentialitylevelsystem.TheroleofMLSsystemsistoenforcethesegregationofdifferentcategoriesofsecuritytypessuchasTop-Secret,Secret,Confidential,andUnclassified.Users,processes,andfilesareassignedtheseclearancelevelsandthesystemmakesaccessdecisionsbasedonacomparisonofthesecuritylevelofeach.Forexample,ausermusthaveaTop-SecretclearancetoaccessaTop-Secretfile.Perhapsthemostflexibleaccesscontrolmodel,whichisasupersetofallothermodels,isrole-basedaccesscontrol(RBAC).Thismodelenablesthedecouplingofvariousentitiesallowingthemtobemodified onthefly withoutextensiverefactoring.Formoreinformation,seetheNISTRBACWebsiteat:http://csrc.nist.gov/rbacFigure9RBACDecouplingRBACdecouplesvariousentitiesassociatedwithaccesscontrol.Figure9isaclassicviewoftheRBACmodel,showingtherelationshipsamongpermissionsonoperationsandobjects,andthesetsofrolesthathavepermissionsforthem.RolesaresimilartoUNIXgroups,buttheyaremoreflexible.Addingandremovingusershaslessofanimpact.AdvancedRBACmodelsincludetheabilitytoinheritpermissionsfromotherrolesandtogoverntheabilitiesgiventousersduringaparticularsession.TheissueswiththePOSIXDACmodelpreventabsolutecontroloverfileaccess.Asecuresystemshouldnotallowuserstochangefileaccessinacapriciousmanner.Additionally,therootusermustbesubject24Untitled Documenttoaccesscontrol.Asecureaccesscontrolmethodneedstosupersedethecontrolsgiventousers,includingtherootuser,anditmustenforceMAC,Multi-Level-Security,andevenRBAC.Advancedaccesscontrolsystems,suchasSELinuxandAppArmor,providethislevelofsecurity.LinuxSecurityModulesToenablefine-grainedaccesscontrol,eliminatethesecurityissuessurroundingthesuperuser,andprovideMAC,theLinuxpermissionmodelneededtobereplaced.ThenewsystemneededtoprovideMAC,yettheDACmodelfoundinmostPOSIXsystemsneededtoremainforbackwardscompatibility.Additionally,othersecurityprojectsneededsupporttoalignwiththeopensourcecommunity scommitmenttomodularityanddiversity,andaccesscontrolneededtooccuratthekernellevelforgreatersecurity.ThesolutionforprovidingmodularityisLinuxSecurityModules(LSM),whichcreatesanagnosticbaseofkernelhooks.Thesehooksenablevariousaccesscontrolpoliciestoimplementasimilar,genericframeworkofkernelaccesscontrolcalls.SELinuxTheNationalSecurityAgency(NSA)fundedresearchoftheSecurityEnhancedLinux(SELinux)toprovidesecurityformedium-needsystems.SELinuximplementstheLSMkernelmodulesandprovisionsrobustMACandRBACcontrolledsystemsmanagedbyfine-grained,customizablesecurityprofiles.AccordingtotheNSASecurity-enhancedLinuxTeam:NSASecurity-enhancedLinuxisasetofpatches(nowincludedinthemainlinekernel)totheLinuxkernelandsomeutilitiestoincorporateastrong,flexiblemandatoryaccesscontrol(MAC)architectureintothemajorsubsystemsofthekernel.Itprovidesamechanismtoenforcetheseparationofinformationbasedonconfidentialityandintegrityrequirements,whichallowsthreatsoftamperingandbypassingofapplicationsecuritymechanismstobeaddressedenablingtheconfinementofdamagethatcanbecausedbymaliciousorflawedapplications.Itincludesasetofsamplesecuritypolicyconfigurationfilesdesignedtomeetcommon,general-purposesecuritygoals.ThedownsideoftheSELinuxvirtuallyinfinitefine-grainedpermissionmodelisthatacomplexsecuritypolicyisrequiredtomanagethesystem.Formoreinformation,seetheNSASELinuxWebsiteat:http://www.nsa.gov/selinux/4AppArmorAspreviouslymentioned,theLSMdesignintentionallycreatesanagnosticframework,implementedbyvariousaccesscontroldesigns.SELinuxisonesuchimplementationandAppArmorisanother.AswithSELinux,AppArmorimplementstheLSMandenforcesMACthroughtheuseofconfigurablesecuritypolicies.AppArmorprovidesfine-grainedcontrolofthesystemaccesscontrol.Formoreinformation,seetheopenSUSEAppArmorWebsiteat:http://en.opensuse.org/ApparmorComparingAppArmorwithSELinuxThemaindifferencebetweenAppArmorandSELinuxisthemeansbywhicheachidentifiesitemsattheatomiclevel.AppArmordoessobyusingpathnames,whereasSELinuxusestraditionalPOSIXinodesforidentification.Thepathnamemethodprovidesamorehuman-friendlydescriptionoftheitems,butitisvulnerabletoacarefullycreatedsymboliclink.Althoughusinginodesforuniqueidentificationavoidsthesymboliclinkrisk,identifyingitemswithinodescanbeoverlycomplex,leadingtosecurityholesduetomisconfiguration.RedHatcurrentlyincludesSELinux,whiletheSUSELinuxdistributionprovidesAppArmor.TheorderofcomplexityforthetwoLSMimplementationsis:1. AppArmorwithPre-definedpolicy2. PredefinedSELinuxpolicy4. NSASecurity-enhancedLinuxTeamhttp://www.nsa.gov/selinux/AdvancedSecurity 25Untitled Document3.Custom policy for AppArmor4.Custom policy for SELinuxMonitoring and Forensic ToolsIt is difficult to detect a compromised system. As soon as an attack succeeds, the attacker will attempt tokeep access to the compromised system while avoiding detection. Systematic auditing is necessary todiscover traces of attacks through unauthorized changes. For example, Tripwire is an auditing tool thatchecks for signs that an intrusion has occurred.For more information, see the Tripwire Web site at:http://www.tripwire.comOften an attacker will place a rootkit on the system to facilitate ongoing control and evasion of detection.Rootkits are sets of applications that alter the very nature of a system, and they are extremely difficult todetect and remove. Rootkits prevent a system from reporting the existence of the rootkit and other files,such as backdoors, key-logging tools, FTP servers, and spam engines left behind by the attack.To ensure that the tools you use are viable, you must not trust the tools on a system you suspect has beenbreached. A live CD solution enables you to examine the suspected system safely and accurately. SecurityTools Distribution (SDT) is an example of a live CD that provides tools for forensic analysis.For more information, see the STD Web site at:http://s-t-d.orgConclusionSecurity is a very complex topic. To begin with, security needs to be viewed in the context of an individualsystem managed with a specific security policy. Perfect security is only theoretically possible. A securitypolicy can describe only what level of security is enough. There is no tool, practice, or silver bullet thatcan ensure that systems are safe and reliable. However, OSMS systems can be made sufficiently secureby keeping security patches up to date, hardening the configuration, using layered security and other bestpractices.The security goals of open source and proprietary systems are not different. To achieve security, you mustaddress the following issues:ManagementCreate a security policy that describes valuable computer assets that need protection.Create processes and an audit schedule to ensure the management of these assets.Ensure that security management is an ongoing activity.EducationBe aware of the evolving security landscape. Understand the best way to meet therequirements of the security policy. Continually educate users about security.VulnerabilityBe aware of security vulnerabilities in the systems you manage as soon as they areannounced and immediately apply security patches.ConfigurationPrepare your system to resist the inevitable attack and to limit the damage of asuccessful attack.New flawsTime exposes new flaws. There is a constant conflict between those who try to protectsystems and those who attack them.GlossaryattackerAn unauthorized person who actively seeks ways to gain control of computer systems.attackAn unauthorized attempt to break into a computer system.brute force attack An unsophisticated attack. In the simplest form, this attack simply tries to guesspasswords or encryption keys by generating strings one after another, until it findsa match. Complex examples of this attack might use dictionaries of common wordsor common passwords. Theoretically, all encryption is susceptible if the attackingsystem has infinite resources (memory and time).certificationauthorityTrusted third parties that issue digital certificates for use by other parties to validatepublic keys.crackersMalicious attackers interested in taking things apart for personal gain or mischief.26Untitled DocumentDMZDemilitarizedzone.Afirewallconfigurationthatsecureslocalareanetworks(LANs).exploits Toolsandmethodsthatpreyuponasystem'svulnerabilities.Viruses,worms,andTrojansaretheautomationofexploits.fingerprinting Theuniqueinformationbywhichsystems,components,OSs,andsoonareidentifiable.hacker Apersoninterestedinfiguringouthowthingsworkbytakingthemapartandputtingthembacktogetherindifferent,interesting,and(hopefully)betterways.hardening Theprocessofsecuringacomputersystemthroughexpertconfiguration,especiallytoprotectagainstattackers.malware Softwareintentionallydesignedforaharmfulpurpose(portmanteauof"MALicioussoftWARE ).non-repudiation Concerningdigitalsecurity,non-repudiationisproofthatamessagehasbeensentorreceived.Thisistypicallyimportantinsituationssuchasbanking(andotherinstances)wheretheinitiationofatransactionmustbeverifiedaswellastheproofthatthetransactionwascompleted.Inotherwords,non-repudiationoforiginprovesthesendingofdata,andnon-repudiationofdeliveryprovesthereceptionofdata.PAMPluggableAuthenticationModules.Asetofmodulesthatenablethedecouplingofcommonsecurityservicesfromthecomponentsthatneedthem.Thesemodulesinclude,amongotherprovisions,theabilitytocheckforpasswordstrengthandaccountpolicies.phishing Theactofsendingane-mailfalselyclaimingtobeanestablished,legitimateenterpriseinanattempttoobtainprivateinformationtobeusedforidentitytheft.Thee-maildirectsrecipientstovisitaWebsitewheretheyareaskedtoupdatepersonalinformation.privilegeescalationAsystemshouldgrantusers,orprocesses,onlytheprivilegesneededfortheimmediatetask.Somesecurityflawsenabletheescalationofprivilege,whichmeansthatauserorprocessobtainsahigher-levelpermissionallowingamaliciousintrudertocircumventtheaccesscontrolsthatweresetforthepreviousprivilegelevel.Manyapplications,includingmanyserverapplications,requiresomeroot-levelprivileges.Iftheseprivilegesarecompromised,theseapplicationscanallowanintruderfullrootprivileges.riskAquantifiableassessmentofsecurity,representedbythispseudo-formula:(Threat Countermeasure) x Value Riskrootkit Asetofsoftwaretoolsintendedtoconcealrunningprocesses,files,orsystemdata,therebyhelpinganintrudertomaintainaccesstoasystemwhileavoidingdetection.securitypolicy Adeclarativedocumentthatidentifiescomputersystemsandcomponentsthatneedsafeguardinganddefinesthedegreetowhichtheyshouldreceiveprotection,butdoesnotdefinehowthisisdone.signature Theuniquemeansbywhichyoucanidentifyanattack,virus,Trojan,orworm.vulnerability Aspecificsecurityflaw.vulnerable Astateinwhichasystemorcomponentissusceptibletoanexploitorexposedtosecurityrisk.whitelist Asetofitemsthatareexplicitlytrusted.Itemscanbenetworkaddresses,users,e-mailaddresses,andsoon.zerodayattack Attacksforwhichnosignatureexists.Glossary 27
