OReilly building secure servers with linux nov 2002 ISBN 0596002173

Tableof
•
Contents
• Index
• Reviews
Reader
•
Reviews
• Errata

BuildingSecureServerswithLinux
ByMichaelD.Bauer

Publisher :O'Reilly
PubDate :October2002
ISBN :0-596-00217-3
Pages :448
Slots :1



Thisbookprovidesauniquebalanceof"bigpicture"
principlesthattranscendspecificsoftwarepackagesand
versionnumbers,andveryclearproceduresonsecuring
someofthosesoftwarepackages.Anall-inclusive
resourceforLinuxuserswhowishtohardentheirsystems,
thebookcoversgeneralsecurityaswellaskeyservices
suchasDNS,theApacheWebserver,mail,filetransfer,

andsecureshell.




BuildingSecureServerswithLinux
ByMichaelD.Bauer


Tableof Publisher :O'Reilly
•
Contents PubDate :October2002
ISBN :0-596-00217-3
• Index
Pages :448
• Reviews
Slots :1
Reader
•
Reviews
• Errata



Copyright



Preface

WhatThisBookIsAbout



TheParanoidPenguinConnection



Audience



WhatThisBookDoesn'tCover



AssumptionsThisBookMakes



ConventionsUsedinThisBook



RequestforComments

Acknowledgments




Chapter1.ThreatModelingandRiskManagement



Section1.1.ComponentsofRisk



Section1.2.SimpleRiskAnalysis:ALEs



Section1.3.AnAlternative:AttackTrees



Section1.4.Defenses



Section1.5.Conclusion



Section1.6.Resources

Chapter2.DesigningPerimeterNetworks



Section2.1.SomeTerminology



Section2.2.TypesofFirewallandDMZArchitectures



Section2.3.DecidingWhatShouldResideontheDMZ



Section2.4.AllocatingResourcesintheDMZ



Section2.5.TheFirewall

Chapter3.HardeningLinux



Section3.1.OSHardeningPrinciples



Section3.2.AutomatedHardeningwithBastilleLinux




Chapter4.SecureRemoteAdministration



Section4.1.WhyIt'sTimetoRetireClear-TextAdminTools



Section4.2.SecureShellBackgroundandBasicUse



Section4.3.IntermediateandAdvancedSSH

Section4.4.OtherHandyTools





Chapter5.Tunneling
Section5.1.StunnelandOpenSSL:Concepts




Chapter6.SecuringDomainNameServices(DNS)



Section6.1.DNSBasics



Section6.2.DNSSecurityPrinciples



Section6.3.SelectingaDNSSoftwarePackage

Section6.4.SecuringBIND



Section6.5.djbdns



Section6.6.Resources




Chapter7.SecuringInternetEmail



Section7.1.Background:MTAandSMTPSecurity



Section7.2.UsingSMTPCommandstoTroubleshootandTestSMTPServers



Section7.3.SecuringYourMTA



Section7.4.Sendmail

Section7.5.Postfix



Section7.6.Resources




Chapter8.SecuringWebServices



Section8.1.WebServerSecurity



Section8.2.BuildTime:InstallingApache



Section8.3.SetupTime:ConfiguringApache



Section8.4.Runtime:SecuringCGIScripts

Section8.5.SpecialTopics



Section8.6.OtherServersandWebSecurity




Chapter9.SecuringFileServices



Section9.1.FTPSecurity



Section9.2.OtherFile-SharingMethods



Section9.3.Resources




Chapter10.SystemLogManagementandMonitoring

Section10.1.syslog



Section10.2.Syslog-ng




Section10.3.TestingSystemLoggingwithlogger



Section10.4.ManagingSystem-LogFiles



Section10.5.UsingSwatchforAutomatedLogMonitoring



Section10.6.Resources




Chapter11.SimpleIntrusionDetectionTechniques

Section11.1.PrinciplesofIntrusionDetectionSystems



Section11.2.UsingTripwire



Section11.3.OtherIntegrityCheckers



Section11.4.Snort



Section11.5.Resources




AppendixA.TwoCompleteIptablesStartupScripts



Colophon

Index


Copyright©2003O'Reilly&Associates,Inc.Allrightsreserved.
PrintedintheUnitedStatesofAmerica.
PublishedbyO'Reilly&Associates,Inc.,1005GravensteinHighway
North,Sebastopol,CA95472.
O'Reilly&Associatesbooksmaybepurchasedforeducational,
business,orsalespromotionaluse.Onlineeditionsarealsoavailablefor
mosttitles().Formoreinformationcontactour
corporate/institutionalsalesdepartment:800-998-9938or

NutshellHandbook,theNutshellHandbooklogo,andtheO'Reillylogo
areregisteredtrademarksofO'Reilly&Associates,Inc.Manyofthe
designationsusedbymanufacturersandsellerstodistinguishtheir
productsareclaimedastrademarks.Wherethosedesignationsappearin
thisbook,andO'Reilly&Associates,Inc.wasawareofatrademark
claim,thedesignationshavebeenprintedincapsorinitialcaps.The
associationbetweenacaravanandthetopicofbuildingsecureservers
withLinuxisatrademarkofO'Reilly&Associates,Inc.
Whileeveryprecautionhasbeentakeninthepreparationofthisbook,
thepublisherandtheauthorassumenoresponsibilityforerrorsor
omissions,orfordamagesresultingfromtheuseoftheinformation
containedherein.


Preface
Computersecuritycanbebothdiscouragingandliberating.Onceyouget
pastthehorrorthatcomeswithfullygraspingitsfutility(afeelingidentical

totheonethatyoungFrenchhornplayersgetuponrealizingnomatter
howhardtheypractice,theirinstrumentwillcontinuetohumiliatethem
periodicallywithoutwarning),yourealizethatthere'snowheretogobut
up.Butifyouapproachsystemsecuritywith:
Enoughcuriositytolearnwhattherisksare
Enoughenergytoidentifyandtakethestepsnecessarytomitigate
(andthusintelligentlyassume)thoserisks
Enoughhumilityandvisiontoplanforthepossiblefailureofeven
yourmostelaboratesecuritymeasures
youcangreatlyreduceyoursystems'chancesofbeingcompromised.At
leastasimportantly,youcanminimizethedurationofanddamage
causedbyanyattacksthatdosucceed.Thisbookcanhelp,onboth
counts.


WhatThisBookIsAbout
Acknowledgingthatsystemsecurityis,onsomelevel,futileismywayof
admittingthatthisbookisn'treallyabout"BuildingSecureServers."[]
Clearly,theonlywaytomakeacomputerabsolutelysecureisto
disconnectitfromthenetwork,poweritdown,repeatedlydegaussits
harddriveandmemory,andpulverizethewholethingintodust.This
bookcontainsverylittleinformationondegaussingorpulverizing.
However,itcontainsagreatdealofpracticaladviceonthefollowing:
[]MyoriginaltitlewasAttemptingtoEnhanceCertainElementsofLinuxSystemSecurityin
theFaceofOverwhelmingOdds:Yo'ArmsTooShorttoBoxwithGod,butthiswasvetoed
bymyeditor(thanks,Andy!).

Howtothinkaboutthreats,risks,andappropriateresponsestothem
Howtoprotectpubliclyaccessiblehostsviagoodnetworkdesign
Howto"harden"afreshinstallationofLinuxandkeepitpatched

againstnewlydiscoveredvulnerabilitieswithaminimumofongoing
effort
Howtomakeeffectiveuseofthesecurityfeaturesofsome
particularlypopularandsecurableserverapplications
Howtoimplementsomepowerfulsecurityapplications,including
NessusandSnort
Inparticular,thisbookisabout"bastionizing"Linuxservers.Theterm
bastionhostcanlegitimatelybeusedseveralways,oneofwhichisasa
synonymforfirewall.(ThisbookisnotaboutbuildingLinuxfirewalls,
thoughmuchofwhatIcovercan/shouldbedoneonfirewalls.)My
definitionofbastionhostisacarefullyconfigured,closelymonitoredhost
thatprovidesrestrictedbutpubliclyaccessibleservicestonontrusted
usersandsystems.Sincethebiggest,mostimportant,andleast
trustworthypublicnetworkistheInternet,myfocusisoncreatingLinux


bastionhostsforInternetuse.
Ihaveseveralreasonsforthisseemingly-narrowfocus.First,Linuxhas
beenparticularlysuccessfulasaserverplatform:eveninorganizations
thatotherwiserelyheavilyoncommercialoperatingsystemssuchas
MicrosoftWindows,Linuxisoftendeployedin"infrastructure"roles,such
asSMTPgatewayandDNSserver,duetoitsreliability,lowcost,andthe
outstandingqualityofitsserverapplications.
Second,LinuxandTCP/IP,thelinguafrancaoftheInternet,gotogether.
AnythingthatcanbedoneonaTCP/IPnetworkcanbedonewithLinux,
anddoneextremelywell,withveryfewexceptions.Therearemany,
manydifferentkindsofTCP/IPapplications,ofwhichIcanonlycovera
subsetifIwanttodosoindepth.Internetserverapplicationsarean
importantsubset.
Third,thisismyareaofexpertise.Sincethemid-ninetiesmycareerhas

focusedonnetworkandsystemsecurity:I'vespentalotoftimebuilding
Internet-worthyUnixandLinuxsystems.Byreadingthisbookyouwill
hopefullybenefitfromsomeoftheexperienceI'vegainedalongtheway.


TheParanoidPenguinConnection
AnotherreasonIwrotethisbookhastodowiththefactthatIwritethe
monthly"ParanoidPenguin"securitycolumninLinuxJournalMagazine.
Aboutayearandahalfago,Irealizedthatallmypiecessofarhad
somethingincommon:eachwasaboutadifferentaspectofbuilding
bastionhostswithLinux.
Bythen,thecolumnhadgainedacertainamountofnotoriety,andI
realizedthattherewasenoughinterestinthissubjecttowarrantanentire
bookonLinuxbastionhosts.LinuxJournalgenerouslygrantedme
permissiontoadaptmycolumnsforsuchabook,andunderthefoolish
beliefthatwritingonewouldamountmainlytoknittingthecolumns
together,updatingthem,andaddingoneortwonewtopics,Iproposed
thisbooktoO'Reillyandtheyaccepted.
Myfollyisyourgain:while"ParanoidPenguin"readersmayrecognize
certaindiagramsandevenparagraphsfromthatmaterial,I'vespenta
greatdealofeffortreresearchingandexpandingallofit,including
retestingallexamplesandprocedures.I'veaddedentire(lengthy)
chaptersontopicsIhaven'tcoveredatallinthemagazine,andI'vemore
thandoubledthesizeandscopeofothers.Inshort,Iallowedthisto
becomeTheBookThatAteMyLifeinthehopeofreducingthenumber
ofuglysecuritysurprisesinyours.


Audience
WhoneedstosecuretheirLinuxsystems?Arguably,anybodywhohas

oneconnectedtoanetwork.Thisbookshouldthereforebeusefulboth
fortheLinuxhobbyistwithawebserverinthebasementandforthe
consultantwhoauditslargecompanies'enterprisesystems.
Obviously,thestakesandthescalediffergreatlybetweenthosetwo
typesofusers,buttheproblems,risks,andthreatstheyneedtoconsider
havemoreincommonthannot.Thesamebuffer-overflowthatcanbe
usedto"root"ahostrunning"Foo-daemonVersionX.Y.Z"isjustasmuch
ofathreattoa1,000-hostnetworkwith50Foo-daemonserversasitisto
a5-hostnetworkwithone.
Thisbookisaddressed,therefore,toallLinuxsystemadministrators
whethertheyadminister1or100networkedLinuxservers,andwhether
theyrunLinuxforloveorformoney.


WhatThisBookDoesn'tCover
ThisbookcoversgeneralLinuxsystemsecurity,perimeter(Internetaccessible)networksecurity,andserver-applicationsecurity.Specific
procedures,aswellastipsforspecifictechniquesandsoftwaretools,are
discussedthroughout,anddifferencesbetweentheRedHat7,SuSE7,
andDebian2.2GNU/Linuxdistributionsareaddressedindetail.
Thisbookdoesnotcoverthefollowingexplicitlyorindetail:
LinuxdistributionsbesidesRedHat,SuSE,andDebian,although
withapplicationsecurity(whichamountstothebetterpartofthe
book),thisshouldn'tbeaproblemforusersofSlackware,
Turbolinux,etc.
OtheropensourceoperatingsystemssuchasOpenBSD(again,
muchofwhatiscoveredshouldberelevant,especiallyapplication
security)
Applicationsthatareinappropriatefororotherwiseunlikelytobe
foundonpubliclyaccessiblesystems(e.g.,SAMBA)
Desktop(non-networked)applications

Dedicatedfirewallsystems(thisbookcontainsasubsetofwhatis
requiredtobuildagoodfirewallsystem)


AssumptionsThisBookMakes
Whilesecurityitselfistooimportanttorelegatetothelistof"advanced
topics"thatyou'llgetaroundtoaddressingatalaterdate,thisbookdoes
notassumethatyouareanabsolutebeginneratLinuxorUnix.Ifitdid,it
wouldbetwiceaslong:forexample,Ican'tgiveaveryfocused
descriptionofsettingupsyslog'sstartupscriptifIalsohavetoexplainin
detailhowtheSystemVinitsystemworks.
Therefore,youneedtounderstandthebasicconfigurationandoperation
ofyourLinuxsystembeforemyproceduresandexampleswillmake
muchsense.Thisdoesn'tmeanyouneedtobeagrizzledveteranof
Unixwho'sbeenrunningLinuxsincekernelVersion0.9andwhocan't
imaginelistingadirectory'scontentswithoutpipingitthroughimpromptu
awkandsedscripts.Butyoushouldhaveaworkinggraspofthe
following:
Basicuseofyourdistribution'spackagemanager(rpm,dselect,etc.)
Linuxdirectorysystemhierarchies(e.g.,thedifferencebetween/etc
and/var)
Howtomanagefiles,directories,packages,useraccounts,and
archivesfromacommandprompt(i.e.,withouthavingtorelyonX)
Howtocompileandinstallsoftwarepackagesfromsource
Basicinstallationandsetupofyouroperatingsystemandhardware
Notablyabsentfromthislistisanyspecificapplicationexpertise:most
securityapplicationsdiscussedherein(e.g.,OpenSSH,Swatch,and
Tripwire)arecoveredfromthegroundup.
Idoassume,however,thatwithnon-security-specificapplications
coveredinthisbook,suchasApacheandBIND,you'reresourceful

enoughtogetanyinformationyouneedfromothersources.Inother


words,newtotheseapplications,youshouldn'thaveanytrouble
followingmyproceduresonhowtohardenthem.Butyou'llneedto
consulttheirrespectivemanpages,HOWTOs,etc.tolearnhowtofully
configureandmaintainthem.


ConventionsUsedinThisBook
Iusethefollowingfontconventionsinthisbook:
Italic
IndicatesUnixpathnames,filenames,andprogramnames;Internet
addresses,suchasdomainnamesandURLs;andnewtermswhere
theyaredefined
Boldface
IndicatesnamesofGUIitems,suchaswindownames,buttons,
menuchoices,etc.
Constantwidth
Indicatescommandlinesandoptionsthatshouldbetypedverbatim;
namesandkeywordsinsystemscripts,includingcommands,
parameternames,andvariablenames;andXMLelementtags
Thisiconindicatesatip,suggestion,orgeneralnote.

Thisiconindicatesawarningorcaution.


RequestforComments
Pleaseaddresscommentsandquestionsconcerningthisbooktothe
publisher:

O'Reilly&Associates,Inc.
1005GravensteinHighwayNorth
Sebastopol,CA95472
(800)998-9938(intheUnitedStatesorCanada)
(707)829-0515(international/local)
(707)829-0104(fax)
Thereisawebpageforthisbook,whichlistserrata,examples,orany
additionalinformation.Youcanaccessthispageat:
/>Tocommentorasktechnicalquestionsaboutthisbook,sendemailto:

Formoreinformationaboutbooks,conferences,ResourceCenters,and
theO'ReillyNetwork,seetheO'Reillywebsiteat:



Acknowledgments
Forthemostpart,mywritingcareerhascenteredondescribinghowto
implementandusesoftwarethatIdidn'twrite.Iamthereforemuch
indebtedtoandevenalittleinaweofthehundredsofoutstanding
programmerswhocreatetheoperatingsystemsandapplicationsIuse
andwriteabout.TheyaretherhinoceroseswhosebacksIpeckfor
insects.
AsifIweren'tbeholdentothoseprogrammersalready,Iroutinelyseek
andreceivefirst-handadviceandinformationdirectlyfromthem.Among
thesegeneroussoulsareJayBealeoftheBastilleLinuxproject,Ron
ForresterofTripwireOpenSource,Balazs"Bazsi"ScheidlerofSyslog-ng
andZorprenown,andRenaudDeraisonoftheNessusproject.
SpecialthanksgotoDr.WietseVenemaoftheIBMT.J.Watson
ResearchCenterforreviewingandhelpingmecorrecttheSMTPchapter.
Nottobelaborthepoint,butIfinditremarkablethatpeoplewhoalready

volunteersomuchtimeandenergytocreateoutstandingfreesoftware
alsotendtobebothpatientandgenerousinreturningemailfrom
completestrangers.
BillLubanovicwrotethesectionondjbdnsinChapter4,andallof
Chapter6,brilliantly,inmyhumbleopinion.Billhasaddedagreatdeal
ofreal-worldexperience,skill,andhumortothosetwochapters.Icould
nothavefinishedthisbookonschedule(anditswebsecuritychapter,in
particular,wouldbelessconvincing!)withoutBill'scontributions.
Iabsolutelycouldnothavesurvivedjugglingmydayjob,fatherlyduties,
magazinecolumn,andresultingsleepdeprivationwithoutan
exceptionallypatientandenergeticwife.Thisbookthereforeowesits
veryexistencetoFeliceAmatoBauer.I'mgratefultoherfor,among
manyotherthings,encouragingmetopursuemybookproposalandthen
forpullingagooddealofmyparentalweightinadditiontoherownafter
theproposalwasacceptedandIwasobligedtoactuallywritethething.


LinuxJournalanditspublisher,SpecializedSystemsConsultantsInc.,
verygraciouslyallowedmetoadaptanumberofmy"ParanoidPenguin"
columnsforinclusioninthisbook:Chapter1throughChapter5,plus
Chapter8,Chapter10,andChapter11contain(oraredescendedfrom)
suchmaterial.Ithasbeenandcontinuestobeapleasuretowritefor
LinuxJournal,andit'ssafetosaythatIwouldn'thavehadenough
credibilityasawritertogetthisbookpublishedhaditnotbeenforthem.
Myapproachtosecurityhasbeenstronglyinfluencedbytwogiantsofthe
fieldwhomIalsowanttothank:BruceSchneier,towhomweallowea
greatdebtforhisongoingcontributionsnotonlytosecuritytechnology
but,evenmoreimportantly,tosecuritythinking;andDr.MartinR.
Carmichael,whoseirresistiblepassionforanduniqueoutlookonwhat
constitutesgoodsecurityhashadanimmeasurableimpactonmywork.

Itshouldbutwon'tgowithoutsayingthatI'mverygratefultoAndyOram
andO'Reilly&Associatesforthisopportunityandfortheirmarvelous
support,guidance,andpatience.Theimpressionsmanypeoplehaveof
O'Reillyasbeingstupendouslysavvy,well-organized,technologically
superior,andinallwayshiparecompletelyaccurate.
Anumberoftechnicalreviewersalsoassistedinfactcheckingand
otherwisekeepingmehonest.RikFarrow,BradfordWillke,andJoshua
Ball,inparticular,helpedimmenselytoimprovethebook'saccuracyand
usefulness.
Finally,intheinevitableamorphouslist,Iwanttothankthefollowing
valuedfriendsandcolleagues,allofwhomhaveaided,abetted,and
encouragedmeasbothawriterandasa"netspook":Dr.DennisR.
GusteratSt.CloudStateUniversity;KoniKayeandJerryJeschkeat
UpstreamSolutions;SteveRoseatVectorInternetServices(whohired
mewaybeforeIknewanythinguseful);DavidW.StacyofSt.Jude
Medical;theentireSAEDesignTeam(youknowwhoyouareordo
you?);MartyJ.WolfatBemidjiStateUniversity;JohnB.Weaver(whom
nobodyinitiallybelievescanpossiblybethatcool,buttheysoonrealize
hecan`causeheis);theReverendGonzoatMusicscene.org;Richard
VernonandDonMartiatLinuxJournal;JayGustafsonofIngenious
Networks;TimN.Shea(who,inmydayjob,hadthethanklesstaskof


standinginformewhileIfinishedthisbook),and,ofcourse,my
dizzyinglyadeptpalsBrianGilbertson,PaulCole,TonyStieber,and
JeffreyDunitz.


Chapter1.ThreatModelingandRisk
Management

SincethisbookisaboutbuildingsecureLinuxInternetserversfromthe
groundup,you'reprobablyexpectingsystem-hardeningprocedures,
guidelinesforconfiguringapplicationssecurely,andotherveryspecific
andlow-levelinformation.Andindeed,subsequentchapterscontaina
greatdealofthis.
Butwhat,really,arewehardeningagainst?Theanswertothatquestion
isdifferentfromsystemtosystemandnetworktonetwork,andinall
cases,itchangesovertime.It'salsomorecomplicatedthanmostpeople
realize.Inshort,threatanalysisisamovingtarget.
Farfromareasontoavoidthequestionaltogether,thismeansthatthreat
modelingisanabsolutelyessentialfirststep(arecurringstep,actually)in
securingasystemoranetwork.Mostpeopleacknowledgethata
sufficientlyskilledanddeterminedattacker[1]cancompromisealmostany
system,evenifyou'vecarefullyconsideredandplannedagainstlikely
attack-vectors.Itthereforefollowsthatifyoudon'tplanagainsteventhe
mostplausibleandlikelythreatstoagivensystem'ssecurity,thatsystem
willbeparticularlyvulnerable.
[1]Asanabstraction,the"sufficientlydeterminedattacker"(someonetheoreticallyableto
compromiseanysystemonanynetwork,outrunbullets,etc.)hasaspecialplaceinthe
imaginationsandnightmaresofsecurityprofessionals.Ontheonehand,inpracticesuch
peoplearerare:justlike"physicalworld"criminals,manyifnotmostpeoplewhoriskthe
legalandsocialconsequencesofcommittingelectroniccrimesarestupidandpredictable.
Themostlikelyattackersthereforetendtoberelativelyeasytokeepout.Ontheother
hand,ifyouaretargetedbyaskilledandhighlymotivatedattacker,especiallyonewith
"insider"knowledgeoraccess,youronlyhopeistohaveconsideredtheworstandnotjust
themostlikelythreats.

Thischapterofferssomesimplemethodsforthreatmodelingandrisk
management,withreal-lifeexamplesofmanycommonthreatsandtheir
consequences.Thetechniquescoveredshouldgiveenoughdetailabout

evaluatingsecurityriskstolendcontext,focus,andtheproperairof
urgencytothetoolsandtechniquestherestofthebookcovers.Atthe


veryleast,Ihopeitwillhelpyoutothinkaboutnetworksecuritythreatsin
alogicalandorganizedway.


1.1ComponentsofRisk
Simplyput,riskistherelationshipbetweenyourassets,vulnerabilities
characteristicoforotherwiseapplicabletothoseassets,andattackers
whowishtostealthoseassetsorinterferewiththeirintendeduse.Of
thesethreefactors,youhavesomedegreeofcontroloverassetsand
theirvulnerabilities.Youseldomhavecontroloverattackers.
Riskanalysisistheidentificationandevaluationofthemostlikely
permutationsofassets,knownandanticipatedvulnerabilities,andknown
andanticipatedtypesofattackers.Beforewebeginanalyzingrisk,
however,weneedtodiscussthecomponentsthatcompriseit.

1.1.1Assets
Justwhatareyoutryingtoprotect?Obviouslyyoucan'tidentifyand
evaluateriskwithoutdefiningpreciselywhatisatrisk.
ThisbookisaboutLinuxsecurity,soit'ssafetoassumethatoneormore
Linuxsystemsareatthetopofyourlist.Mostlikely,thosesystems
handleatleastsomedatathatyoudon'tconsidertobepublic.
Butthat'sonlyastart.Ifsomebodycompromisesonesystem,whatsort
ofriskdoesthatentailforothersystemsonthesamenetwork?Whatsort
ofdataisstoredonorhandledbytheseothersystems,andisanyofthat
dataconfidential?Whataretheramificationsofsomebodytamperingwith
importantdataversustheirsimplystealingit?Andhowwillyour

reputationbeimpactedifnewsgetsoutthatyourdatawasstolen?
Generally,wewishtoprotectdataandcomputersystems,both
individuallyandnetwork-wide.Notethatwhilecomputers,networks,and
dataaretheinformationassetsmostlikelytocomeunderdirectattack,
theirbeingattackedmayalsoaffectotherassets.Someexamplesof
thesearecustomerconfidence,yourreputation,andyourprotection
againstliabilityforlossessustainedbyyourcustomers(e.g.,e-commerce


sitecustomers'creditcardnumbers)andforlossessustainedbythe
victimsofattacksoriginatingfromyourcompromisedsystems.
Theassetof"nonliability"(i.e.,protectionagainstbeingheldlegallyor
evencriminallyliableastheresultofsecurityincidents)isespecially
importantwhenyou'redeterminingthevalueofagivensystem'sintegrity
(systemintegrityisdefinedinthenextsection).
Forexample,ifyourrecoveryplanforrestoringacompromisedDNS
serverissimplytoreinstallRedHatwithadefaultconfigurationplusa
fewminortweaks(IPaddress,hostname,etc.),youmaybetemptedto
thinkthatthatmachine'sintegrityisn'tworthverymuch.Butifyou
considertheinconvenience,badpublicity,andperhapsevenlegalaction
thatcouldresultfromyoursystem'sbeingcompromisedandthenusedto
attacksomeoneelse'ssystems,itmaybeworthspendingsometimeand
effortonprotectingthatsystem'sintegrityafterall.
Inanygivencase,liabilityissuesmayormaynotbesignificant;thepoint
isthatyouneedtothinkaboutwhethertheyareandmustincludesuch
considerationsinyourthreatanalysisandthreatmanagementscenarios.

1.1.2SecurityGoals
Onceyou'vedeterminedwhatyouneedtoprotect,youneedtodecide
whatlevelsandtypesofprotectioneachassetrequires.Icallthetypes

securitygoals;theyfallintoseveralinterrelatedcategories.
1.1.2.1Dataconfidentiality
Sometypesofdataneedtobeprotectedagainsteavesdroppingand
otherinappropriatedisclosures."End-user"datasuchascustomer
accountinformation,tradesecrets,andbusinesscommunicationsare
obviouslyimportant;"administrative"datasuchaslogoncredentials,
systemconfigurationinformation,andnetworktopologyaresometimes
lessobviouslyimportantbutmustalsobeconsidered.


Theramificationsofdisclosurevaryfordifferenttypesofdata.Insome
cases,datatheftmayresultinfinancialloss.Forexample,anengineer
whoemailsdetailsaboutanewinventiontoacolleaguewithoutusing
encryptionmayberiskingherabilitytobefirst-to-marketwithaparticular
technologyshouldthosedetailsfallintoacompetitor'spossession.
Inothercases,datadisclosuremightresultinadditionalsecurity
exposures.Forexample,asystemadministratorwhousestelnet(an
unencryptedprotocol)forremoteadministrationmayberiskingdisclosure
ofhislogoncredentialstounauthorizedeavesdropperswhocould
subsequentlyusethosecredentialstogainillicitaccesstocritical
systems.
1.1.2.2Dataintegrity
Regardlessoftheneedtokeepagivenpieceorbodyofdatasecret,you
mayneedtoensurethatthedataisn'talteredinanyway.Wemostoften
thinkofdataintegrityinthecontextofsecuredatatransmission,but
importantdatashouldbeprotectedfromtamperingevenifitdoesn'tneed
tobetransmitted(i.e.,whenit'sstoredonasystemwithnonetwork
connectivity).
ConsidertheramificationsofthefilesinaLinuxsystem's/etcdirectory
beingalteredbyanunauthorizeduser:byaddingherusernametothe

wheelentryin/etc/group,ausercouldgrantherselftherighttoissuethe
commandsuroot-.(She'dstillneedtherootpassword,butwe'dprefer
thatshenotbeabletogeteventhisfar!)Thisisanexampleoftheneed
topreservetheintegrityoflocaldata.
Let'stakeanotherexample:asoftwaredeveloperwhomakesgames
availableforfreeonhispublicwebsitemaynotcarewhodownloadsthe
games,butalmostcertainlydoesn'twantthosegamesbeingchanged
withouthisknowledgeorpermission.Somebodyelsecouldinjectvirus
codeintoit(forwhich,ofcourse,thedeveloperwouldbeheld
accountable).
Weseethenthatdataintegrity,likedataconfidentiality,maybedesiredin


anynumberandvarietyofcontexts.
1.1.2.3Systemintegrity
Systemintegrityreferstowhetheracomputersystemisbeingusedasits
administratorsintend(i.e.,beingusedonlybyauthorizedusers,withno
greaterprivilegesthanthey'vebeenassigned).Systemintegritycanbe
underminedbothbyremoteusers(e.g.,connectingoveranetwork)and
bylocalusersescalatingtheirownlevelofprivilegeonthesystem.
Thestateof"compromisedsystemintegrity"carrieswithittwoimportant
assumptions:
Datastoredonthesystemoravailabletoitviatrustrelationships
(e.g.,NFSshares)mayhavealsobeencompromised;thatis,such
datacannolongerbeconsideredconfidentialoruntamperedwith.
Systemexecutablesthemselvesmayhavealsobeencompromised.
Thesecondassumptionisparticularlyscary:ifyouissuethecommand
psauxwtoviewallrunningprocessesonacompromisedsystem,are
youreallyseeingeverything,orcouldthepsbinaryhavebeenreplaced
withonethatconvenientlyomitstheattacker'sprocesses?

Acollectionofsuch"hacked"binaries,whichusuallyincludes
bothhackingtoolsandalteredversionsofsuchcommon
commandsasps,ls,andwho,iscalledarootkit.Asadvanced
orarcaneasthismaysound,rootkitsareverycommon.

Industrybestpractice(nottomentioncommonsense)dictatesthata
compromisedsystemshouldundergo"bare-metalrecovery";i.e.,itshard
drivesshouldbeerased,itsoperatingsystemshouldbereinstalledfrom
sourcemedia,andsystemdatashouldberestoredfrombackupsdated
beforethedateofcompromise,ifatall.Forthisreason,systemintegrity
isoneofthemostimportantsecuritygoals.Thereisseldomaquick,


easy,orcheapwaytorecoverfromasystemcompromise.
1.1.2.4System/networkavailability
Theothercategoryofsecuritygoalswe'lldiscussisavailability."System
availability"isshortfor"thesystem'savailabilitytousers."Anetworkor
systemthatdoesnotrespondtouserrequestsissaidtobe"unavailable."
Obviously,availabilityisanimportantgoalforallnetworksandsystems.
Butitmaybemoreimportanttosomethanitistoothers.Anonline
retailer'swebsiteusedtoprocesscustomers'orders,forexample,
requiresamuchgreaterassuranceofavailabilitythana"brochure"web
site,whichprovidesastore'slocationandhoursofoperationbutisn't
actuallypartofthatstore'scorebusiness.Intheformercase,
unavailabilityequalslostincome,whereasinthelattercase,itamounts
mainlytoinconvenience.
Availabilitymayberelatedtoothersecuritygoals.Forexample,suppose
anattackerknowsthatatargetnetworkisprotectedbyafirewallwithtwo
vulnerabilities:itpassesalltrafficwithoutfilteringitforabriefperiod
duringstartup,anditcanbemadetorebootifbombardedbyacertain

typeofnetworkpacket.Iftheattackersucceedsintriggeringafirewall
reboot,hewillhavecreatedabriefwindowofopportunityforlaunching
attacksthatthefirewallwouldordinarilyblock.
Thisisanexampleofsomeonetargetingsystemavailabilitytofacilitate
otherattacks.Thereversecanhappen,too:oneofthemostcommon
reasonscyber-vandalscompromisesystemsistousethemaslaunchpointsfor"DistributedDenialofService"(DDoS)attacks,inwhichlarge
numbersofsoftwareagentsrunningoncompromisedsystemsareused
tooverwhelmasingletargethost.
Thegoodnewsaboutattacksonsystemavailabilityisthatoncethe
attackends,thesystemornetworkcanusuallyrecoververyquickly.
Furthermore,exceptwhencombinedwithotherattacks,DenialofService
attacksseldomdirectlyaffectdataconfidentialityordata/systemintegrity.