SUBMITTED TO THE FACULTY OF GRADUATE STUDIES

ii

THEUNIVERSITYOFCALGARY

EnhancingFirewalls:ConveyingUserandApplicationIdenti cationto

NetworkFirewalls

by

ReinderdGordonNathandeGraaf

ATHESIS

SUBMITTEDTOTHEFACULTYOFGRADUATESTUDIESINPARTIALFULFILLMENTOFTHEREQUIREMENTSFORTHE

DEGREEOFMASTEROFSCIENCE

DEPARTMENTOFCOMPUTERSCIENCE

CALGARY,ALBERTA

MAY,2007

cReinderdGordonNathandeGraaf2007

ii

THEUNIVERSITYOFCALGARYFACULTYOFGRADUATESTUDIES

Theundersignedcertifythattheyhaveread,andrecommendtotheFacultyofGrad-uateStudiesforacceptance,athesisentitled“EnhancingFirewalls:ConveyingUserandApplicationIdenti cationtoNetworkFirewalls”submittedbyReinderdGordonNathandeGraafinpartialful llmentoftherequirementsforthedegreeofMasterofScience.

Dr.MichaelJohnJacobson,Jr.,Supervisor,

DepartmentofComputerScience.Dr.ZongpengLi,Internalexaminer

DepartmentofComputerScience.

Dr.JohnAycock,Co-Supervisor,

DepartmentofComputerScience.

Dr.BehrouzFar,Externalexaminer

DepartmentofElectrical&Com-puterEngineering.

Date

ii

ii

Abstract

Firewallsareusedtoprotectnetworksfrommalicioustra cfromtheoutsideandlimitthe owofinformationfrominsideprotectednetworkstotheoutsideworld.Most rewalls ltertra cbasedonnetworkaddressesandpacketcontents.Unfortunately,onemajorgoalof rewalling,thatoflimitingtheusersandprogramsthatcancom-municate,isnotwellservedbysuchdesigns:itisdi culttoaccuratelymapnetworkaddressesandpacketcontentstouserandprogramnames.

Firewallscansolvetheproblemofsecurelymappingusernamestoaddresseswhen lteringinboundtra cfromuntrustednetworksthroughtheuseofcovertauthenti-cationsystemssuchasportknockingandsinglepacketauthorization.Egress rewallscanidentifyusersandprogramsontrustednetworksthroughtheuseofapplication- lters.Inthisthesis,Isurveythecurrentstateofbothtypesofsystems,describetheirweaknesses,andintroducetechniquestoalleviatesomeoftheseweaknesses.

iii

ii

Acknowledgements

First,Imustthankmysupervisors,JohnAycockandMichaelJacobson,forguidingmethroughmydegreeandputtingupwithmyfrequenttopicchanges.Withouttheirpatienceandsupport,Ineverwouldhave nishedthis.

Also,myexperimentalanalysisofUDPpacketdroppingandout-of-orderdeliverywouldnothavebeenpossiblewithouttheassistanceofAndr´eBaron,BryanKadzbanandPatrickLucas,whovolunteeredhomecomputersastargetsformypacketgener-ator.

Finally,Imustthankmymother,fordonatingafewdaysofhertimetohelpmeeditthisthesis,andforhavingbeatenmeovertheheadwithagrammarstickthroughoutgradeschooluntilIcouldwritedecently.

iv

ii

TableofContents

ApprovalPageAbstract

AcknowledgementsTableofContentsListofTablesListofFiguresListofAlgorithms

1Introduction

1.1ProblemswithExistingFirewallTechnology...............1.2Contributionsofthisthesis.........................2Background

2.1IntroductiontoNetworking............

2.1.1NetworkandTransportProtocols.....2.1.2NetworkApplicationArchitectures....2.1.3VulnerabilitiesinInternetProtocols....2.2IntroductiontoCryptography...........

2.2.1SecurityServices..............2.2.2SymmetricCiphers.............2.2.3CryptographicHashFunctions.......2.2.4MessageAuthenticationCodes.......2.2.5AsymmetricCiphers............2.2.6DigitalSignatures..............2.2.7KeyExchangeAlgorithms.........2.2.8AttacksAgainstCryptographicAlgorithms2.3AttacksandO ensiveTechnologies........

2.3.1PortScans..................2.3.20-DayExploits...............2.3.3WormsandMalware............2.3.4Denial-of-ServiceAttacks..........2.4FirewallsandDefensiveTechnologies.......

2.4.1Firewalls...................2.4.2IntrusionDetectionSystems........2.4.3NetworkAddressTranslators.......

v

........................................................................................................................................................................................................................................................................

iiiiiivvviiiixx1246671011121313141515161718212122232425253638

ii

2.4.4VPNsandEncryptedChannels..................

...........................................................................................................................................................................................................

404245484955626567686970717272737575777982838586888990919293959696979899102105

3StealthyAuthenticationMechanisms

3.1CovertChannelsoverNetworks............3.2PortKnocking......................

3.2.1AuthenticationUsingPortKnocking.....3.2.2PortKnockingSystemDesigns........3.2.3WeaknessesofPortKnocking.........3.2.4UsesofPortKnockinginMalware......3.2.5DistinguishingPortKnockingfromPortScans3.3SinglePacketAuthorization..............

3.3.1AdvantagesofSPA...............3.3.2DisadvantagesofSPA.............3.3.3VariationsonSPA...............3.3.4Active-covertSPA...............3.4Application-layerCovertChannels...........3.5Concernsabout“SecuritybyObscurity”.......

4ImprovementstoPortKnockingandSPA

4.1Challenge-responseKnocking....................

4.1.1BasicUnilateralAuthentication...............4.1.2AuthenticationinthePresenceofNATs..........4.1.3MutualAuthentication....................4.1.4AnalysisofChallenge-responseAuthentication.......4.2Disorder-resistantKnocking.....................

4.2.1UsingInter-packetDelays..................4.2.2UsingSequenceNumberFields...............4.2.3UsingDisjoint,MonotonicallyIncreasingRanges......4.2.4UsingDi erencesinaMonotonicallyIncreasingRange..4.2.5RepeatingSequenceNumbers................4.3AlternatePortKnockingEncodings.................

4.3.1PermutationKnocking....................4.3.2BitKnocking.........................4.4PreventingRaceAttacks.......................

4.4.1Server-chosenPortNumbers.................4.4.2TCPISNAgreement.....................4.4.3CombiningAuthenticationandConnectionEstablishment4.5ImplementingPortKnockingandSPA...............

4.5.1PerformanceofSPAandPortKnocking..........4.6Summary...............................

vi

ii

5ImprovementstoApplicationFiltering

5.1ExistingApplicationFilteringSystems.......5.2ProblemswithApplicationFiltering.........

5.2.1DealingwithUnrecognizedApplications..5.2.2ApplicationSpoo ng.............5.2.3InterpretedLanguagesandVirtualization..5.2.4ConnectionsbyProxy............5.2.5AttacksAgainstFirewallingSoftware....5.3AnImprovedArchitectureforApplicationFiltering

5.3.1ApplicationFilteringbyNetworkFirewalls.5.3.2PreventingApplicationSpoo ng.......5.3.3DetectingConnectionsbyProxy.......5.4ImplementinganApplicationFirewall........

....................................................................................................................................

107108109109111112114114115115118120123

6ConclusionsandFutureWork1276.1ContributionsofthisThesis........................1276.2OpportunitiesforFutureWork......................130BibliographyAAnA.1A.2A.3A.4

ExperimentinOut-of-OrderPacketDeliveryRelatedWork....................ExperimentalDesign................Results........................Conclusions.....................

................................................133154154155157168170

BProofThatPermutationKnockingIsIne cient

vii

ii

4.1Estimatedexecutiontimesforportknocking...............85

4.2ExecutiontimeforportknockingusingAlgorithm4.1andinter-packetdelays874.3Percentdi erenceinestimatedexecutiontimeforportknockingusing

Algorithm4.1andinter-packetdelaysrelativetothesamealgorithm

withoutdelays................................874.4Estimatedexecutiontimesandportrangesizesforportknockingusing

Algorithm4.1andsequencenumber elds................894.5Estimatedexecutiontimesandportrangesizesforportknockingusing

disjoint,monotonicallyincreasingranges.................904.6Testnetworkcharacteristics........................1044.7ExecutiontimesforSPA,portknocking,andSSH............1055.1ProcessgroupsforallprocessesinFigure5.1...............122A.1A.2A.3A.4A.5

Locationsoftargetsfortheout-of-orderdeliveryexperimentSummaryofresultsusing0msinter-packetdelays......Summaryofresultsusing1msinter-packetdelays......Summaryofresultsusing2msinter-packetdelays......Averageinter-packettimeswhensendingandreceiving...

..............................156158158159167

viii

ii

2.1TCPconnectionestablishmenthandshake................2.2FlawinUDPstatetracking........................2.3Tra cpassingthroughaNAT.......................3.1Simpleportknockingexample.Aportisopenedinthe rewallin

responsetoaspeci cportsequence.....................3.2SPAexample.Aportisopenedinthe rewallinresponsetoanau-thenticationpacket..............................4.1TheMa afraud.AandBthinkthatthattheyareauthenticatingto

eachother,butCisforwardingmessagesbetweenthemwiththegoalofconvincingAthatitisBandBthatitisA..............

930395069

81

5.1Graphofcausalrelationshipsbetweenprocesses..............122A.1Out-of-orderpacketsusing0bytepayloads.............A.2Magnitudeoferrorsusing0bytepayloads.............A.3Out-of-orderpacketsusing100bytepayloads............A.4Magnitudeoferrorsusing100bytepayloads............A.5Out-of-orderpacketsusing500bytepayloads............A.6Magnitudeoferrorsusing500bytepayloads............A.7Packetlossusing0byteUDPpayloads...............A.8Packetlossusing100byteUDPpayloads..............A.9Packetlossusing500byteUDPpayloads..............A.10Target1:inter-packetarrivaltimesusing0byteUDPpayloads..A.11Target1:inter-packetarrivaltimesusing100bytepayloads...A.12Target1:inter-packetarrivaltimesusing0msinter-packetdelays

....................................161161162162163163164164165165166166

ix

ii

ListofAlgorithms

4.14.24.34.44.5

Challenge-responseunilateralauthentication....NAT-awareunilateralauthentication........AttackagainstNAT-awareunilateralauthenticationChallenge-responsemutualauthentication.....Keyedsetpermutation................

.......................................................7780808393

x

ii

Chapter1Introduction

Securityhole

Open,youareinsecureClosed,youarenothreat

–Shidoshi,

Inancienttimes,townsandvillageswerebasedaroundmarket-places,wheregoodsfrommanysourcescouldbetradedfreely.Overtime,astownsgrewintocitiesandgatheredwealth,barbariansgrewenviousofthecity-dwellers.Inresponsetothisthreat,citieserecteddefensivewallstoprotectagainstoutsiders.However,asthecitieswerestilldependentontrade,thewallsneededtohavemanygatestoallowpassageinandoutofthecities;guardsmonitoredwhoenteredandexitedandattemptedtokeepthebarbariansout.

SoitiswiththeInternet.When rstcreated,itwasdesignedtofostersharingandcollaboration.Truetothisgoal,itwasbuilttobeasopenaspossible,ter,asthreatsgrew,networkadministratorsdeployed rewalls,whichrestrictthenetworktra callowedtoenterandleavelocalnetworks,whilestillallowing“legitimate”tra ctopass.

Unfortunately,discriminatingbetween“legitimate”and“illegitimate”tra cisnoteasy.Thebestpracticeistoallowonlytra cthatisexplicitlyrecognizedaslegitimatewhileblockingeverythingelse,butthisiseasiersaidthandone.Factorstotakeintoaccountwhenexaminingtra cincludesources,destinations,theusersandprogramsthatsentorwillreceivethetra c,theinformationbeingexchanged,theformatoftheinformationbeingexchanged,thetimeofday,thevolumeoftra cthathasbeensentbythesource,andothers;whilenotallofthesearenecessarilyappropriateunder

ii

allcircumstances,othersthatareimportantarefrequentlyignoredduetolackofinformationorthedi cultyofchecking.Also,nodefensivemeasureisperfect:wallscanbescaledwithladdersorbattereddownbytrebuchets,andsecuritysoftwarecanbedisabledorbypassedbyexploitingsoftwareorcon gurationvulnerabilities.Forthisreason,security(ofbothcitiesandcomputers)dependsontheprincipleofdefenseindepth:theprinciplethatsecuritycomesinlayers,wherethedefeatofonelayerdoesn’tleaveeverythingvulnerableandthatattackersmustbypassmultiplelayerstoreachanythingimportant.

1.1ProblemswithExistingFirewallTechnology

Mostmodern rewallsaredesignedto lterpacketsorvalidateprotocolsemantics,andtheyareverygoodatthis.However,behindthepacketsandprotocolmessagesvisibleto rewallsareusersandprograms; rewallshavelittleknowledgeoftheseandconsequentlyaren’tverygoodat lteringbasedontheusersandprogramsresponsiblefornetworktra c.Thiscanbeviewedastwoseparateproblems:thatof lteringbyuseroningress,andthatof lteringbyuserandprogramonegress.

1.Firewallscaneasilylimitwhatservicescanbereachedfromoutside.However,itmayalsobenecessarytolimitwhichuserscanconnecttothoseservices.Acommonassumption,madebymanymodern rewalls,isthattrustedusersonlyconnectfromsmallsetsoftrustedhostswithspeci caddresses;theyimplementuser lteringbyblockingincomingpacketswithsourceaddressesnotinthesesets.Unfortunately,thesourceaddressesonincomingpacketstelllittleabouttheuserwhosentthem;malicioususerscanspooftrustedhosts,andtrusteduserscanconnectfromuntrustedhosts.Sincemanytrustedhostsmayhavedynamic(DHCP-assigned)IPaddresses,openinga rewalltoonetrustedhost

ii

mayrequireopeningittothousandsofIPaddresses,makingiteasierforanattackerto ndanaddresstospooforamachinewithatrustedaddresstohijack.AdjustingthesetoftrustedIPaddressestypicallyinvolveseithermanualrecon gurationbya rewalladministratororconnectingtosomeworld-accessibleauthenticationservice,whichitselfmaybevulnerabletoattack.

2.AlthoughusersusuallycanbeaccuratelylinkedtoIPaddresseswithinalocalnetwork,itcanbedi culttolimittheserviceswithwhichthoseusersareal-lowedtocommunicate.Firewallsgenerallyattemptto lteroutboundtra cbyrestrictingtheportstowhichusersmayconnect:forexample,disallowingout-boundconnectionstoanythingexceptTCPports80(HTTP),443(HTTPS),and20and21(FTP).Unfortunately,thisisn’tparticularlye ective:non-standardservicesmayberunningontheseallowedports.Whereasapplication-layer re-wallscaneasily ltertra cthatdoesn’tmatchtheexpectedprotocolforaport,itismuchmoredi culttodetectdisallowedapplicationsthattunneltra cthroughstandardprotocolsonstandardports.Forinstance,tunnellingvariousprotocolsthroughport80,normallyusedforunencryptedWWWtra c,hasbecomequitecommon[Alb04,BP04],andencryptionrendersmostapplication-layer ltersuseless.Also,standardprotocolscanrunonstandardportsandstillbeusedforunauthorizedpurposes.Restrictingnetworkaccesstoonlyauthorizedlocalusersandprogramshasthepotentialtoalleviatetheseproblems,butinfor-mationabouttheusersandapplicationsthatgeneratedorwillreceivenetworktra cisusuallyonlyavailableatthesourceordestinationhoststhemselves,andisn’tnecessarilyreliable.

ii

1.2Contributionsofthisthesis

Thisthesisintroducesanddescribesmethodsforaddressingbothoftheseprob-lems.The rstcanbeaddressedbyusingcovertauthenticationsystems,systemsthatallowuserstoauthenticatewithoutmakingtheirpresenceeasyforattackerstodetect,toallowlegitimateuserstoinformingress rewallsoftheircurrentnetworkaddressesandrequestthatsubsequentconnectionsbeaccepted.Twosuchsystemsusedtodayareportknockingandsinglepacketauthorization(SPA);Isurveyexistingdesignsforbothandhighlighttheirstrengthsandweaknesses.Ofparticularconcernaretheirweaknesses:botharefrequentlyimplementedwithinsecureauthenticationsystems,donotauthenticateserverstoclients,failinthepresenceofnetworkaddresstranslation,aresusceptibletodenial-of-serviceattacks,anddonotlogicallyassociateauthenticationexchangeswiththenetworkconnectionsthattheyenable.Portknock-inginparticularishighlyvulnerabletopacketlossandreordering.Withthese awsinmind,IthenproposetechniquesthatcanbeusedtoimproveonexistingportknockingandSPAsystems.Challenge-responseauthenticationprovidesbothcryptographicallysecureauthenticationandamethodtoauthenticationserverstoclients;IproposeportknockingandSPAdesignsusingchallenge-responseauthenticationandshowthattheoverheadimposedbysuchasystemisnotunreasonableundermostcircumstances.Ipresentexperimentalanalysisquantifyingthedegreeofpacketlossandre-orderinginpacketstreamstypicalofportknocking,anddescribeandcompareseveraltechniquesforensuringthatmessagestransmittedbyportknockingcanbeproperlyreassembledondelivery,regardlessofthedegreeofreordering.Ialsoproposeseveralnovelde-signsforportknockingsystemsanddiscusstheirstrengthsandweaknessescomparedtoexistingsystems.Finally,Ipresentanddiscussseveralmethodsforcreatinglogi-calassociationsbetweenauthenticationexchangesandsubsequentconnections.This

ii

materialexpandsandimprovesonmypreviouslypublishedwork[dAJ05].

Thesecondproblemcanbeaddressedbyextendingthecapabilitiesofapplication- ltering rewalls.Existingsystemsgenerallyonlyprovideapplication lteringonhost rewalls;Idiscusstheadvantagesofextendingnetwork rewallstoalsoprovideapplication lteringandmechanismsforcommunicatinguserandprograminformationtonetwork rewalls.Manydesignsforapplication lteringdonotdetectmaliciousprogramsmasqueradingaslegitimateonesundercertaincircumstances;Isuggestwaysofpreventingthisthroughtheuseofintegrityshells,butpointoutthatsolvingthisproblemrequiresthattheoperatingsystemsofhostsusingapplication lteringmustbetrustedbythe lteringsystem.Also,application lteringisine ectiveagainstinterpretedprogramsandthoserunninginsidevirtualmachines,unlesstheinterpretersandvirtualenvironmentsarealsotrusted.Finally,existingnetwork rewallsdonotalwaysreliablydetectwhenoneprocessusesanotherasaclient,potentiallyallowingmaliciousoruntrustedprogramstomakeunauthorizednetworkconnections.Tosolvethisproblem,Ipresentanalgorithmfortrackinginter-processcommunicationthatcanidentifymostsuchattempts.

Chapter2providesbackgroundinformationonnetworksandsecurity.InChapter3,Ipresentmysurveyofportknockingandsinglepacketauthorization,whileChapter4presentsimprovementstoportknockingandSPA.Chapter5containsmyproposedenhancementstoapplication lters.Finally,Chapter6givesmyconclusionsandsuggestionsforfurtherwork.

ii

Chapter2Background

Thewireprotocolguysdon’tworryaboutsecuritybecausethat’sreallyanetworkprotocolproblem.Thenetworkprotocolguysdon’tworryaboutitbecause,really,it’sanapplicationproblem.Theapplicationguysdon’tworryaboutitbecause,afterall,theycanjustusetheIPaddressandtrustthenetwork.

–MarcusJ.Ranum

Asbackgroundfortheideaspresentedinthefollowingchapters,thischapterpresentsageneraloverviewofnetworking,cryptography,andrelevanto ensiveanddefensivecomputersecuritytechnologies.

2.1IntroductiontoNetworking

TheInternetwasdesignedinthe1960s,’70sand’80sasarobustcommunicationsystembetweendiverselocalnetworks.Itsdesignisbasedonastackof veprotocollayers:

1.Physical–responsibleforencodinganddecodingsignalsoveratransmissionmedium,suchasawire,optical ber,radiofrequency,oraviancarrier;2.Datalink–responsibleforcommunicationbetweenhostsonaphysicalnetworksegment;

work–responsibleforglobaladdressingandroutingpacketsbetweenphys-icalnetworksegments;

4.Transport–responsibleforcommunicationbetweenprocesses,andoptionally,reliableconnections;

ii

5.Application–responsibleforencodinganddecodinginformationinformatsunderstoodbyapplications,aswellasprovidinganynecessaryservicesnotpro-videdbylowerlayers.

Eachprotocollayerprovidesservicestolayersaboveit;informationbeingsentispasseddownfromtheapplicationlayertothephysicallayer,witheachlevelperform-ingtransformationsappropriatetothatlayer,beforethephysicallayerhandlestheactualworkoftransmission.Wheninformationisreceived,eachprotocollayerundoesitstransformationsandpassesinformationbackupthestack,untilitreachestheap-plicationlayer.ThisdesignissimilartotheOSInetworkstackmodel[Tan96],whichmandatessevenlayersandasomewhatdi erentbreakdownofresponsibilities.TheinfrastructureoftheInternetconsistsofanumberofrouters,interconnectedcomputerswhosefunctionistoforwardinformationfromitssourcetoitsintendeddestination;theprocessof putersandotherdevicesthatcommunicateovertheInternetareknownashosts.2.1.1

NetworkandTransportProtocols

ThestandardnetworkprotocolontheInternetisknownastheInternetProtocol,version4(IPv4)[Pos81c].(Inthisthesis,theabbreviation“IP”,for“InternetPro-tocol”,alwaysreferstoIPv4;thenext-generationInternetprotocol,IPv6willnotbediscussed.)IPprovidesanunreliabledatagramservice:itbreakstheinformationthatittransmitsintopackets(alsoknownasdatagrams)androuteseachtoitsdestinationindependently,butprovidesnoguaranteesthatpacketsareproperlydelivered.Packetsmaybedropped,duplicated,delayed,re-ordered,orcorruptedintransit;errormes-sages(intheformofICMPpackets[Pos81b])mayormaynotbereturnedifdelivery

ii

fails.IPpacketscontainaheaderof20to60bytesandapayloadof8to65,516bytesofdata;packetsizesareselectedbasedonthepropertiesoflowerprotocollayers.IPheaderscontainmetadatathatenablespacketstoberoutedtotheirdestinations,suchastheaddressesofpackets’sourcesanddestinations.IPaddressesare32-bitnumbersandarenotnecessarilyunique;routersnecessarilyhavemorethanoneaddress,andsometechniquesallowhoststoshareIPaddresses.

TheInternetdoesn’tstrictlyfollowtheOSIstackmodel:variousprotocolsexistthatallowIPpacketstobeencapsulatedinsideprotocolsthatrunontopofIP.Thisencapsulationofprotocolsisknownastunnelling.Forinstance,IPsec(asecurityarchitectureforIP)[KS05]cancreateencryptedtunnelsforIPandothernetworkprotocolsontopofIP,whereasGRE(“GenericRoutingEncapsulation”)[FLH+00]cancreateplain-texttunnels.Moreinformationontunnellingisavailablein[CBR03].Anumberoftransportlayersexist,eachprovidingdi erentservices.ICMP(“In-ternetControlMessageProtocol”)isusedfordeliveringmanytypesoferrormessagesfromthenetworkandtransportlayersaswellasperformingavarietyofadministrativefunctions[Pos81b].UDP(“UserDatagramProtocol”)providesanunreliabledatagramservicebetweenapplications[Pos80];theonlyimportantfeaturethatitaddstoIPisapplicationaddressing.TCP(“TransmissionControlProtocol”),themostcommontransportprotocolontheInternet,providesreliablebidirectionalstreamsbetweenapplications[Pos81a].Othertransportprotocolsexist,providingotherservices.TCPbreaksstreamsdownintosegmentswhicharethenencapsulatedintoIPpackets.LikeIPpackets,TCPsegmentscontainbothheadersandpayloaddata.TCPassignssequencenumberstoeverybyteofpayloaddatasentandrequiresthateverybytebeacknowledged;ifanysegmentsarelostorcorrupted,eithertheywillberesentoranerrorwillbedetected.Duplicateandout-of-orderpacketscanalsobedetected

ii

andcorrectedusingthesequencenumbers.TCPheaderscontainapplication-layeraddresses,dataandacknowledgementsequencenumbers,andcontrol ags,amongother elds.SegmentsusedtoinitiateconnectionshavetheSYN(“synchronize”) agset;thoseusedto nalizeconnectionshavetheFIN agset.TheACK agindicatesthatasegmentisacknowledgingdatareceivedfromtheotherendoftheconnection.OpeningaTCPconnectionrequiresthatbothendpointsexchangeinitialsequencenumbers(ISNs)usinganalgorithmknownasthethree-wayhandshake,showninFigure

2.1.TheclientstartsthehandshakebychoosinganISNandsendingittotheserverinasegmentwiththeSYN agset.Iftheserverchoosestoaccepttheconnection,itrespondswithitsownISNinasegmentcarryingtheSYN ag;italsosignalsthatitreceivedtheclient’sISNbysettingitsacknowledgementnumbertotheclient’sISNplusoneandsettingtheACK ag.Theclientthenacknowledgesreceiptoftheserver’sISNwithanACKsegmentcarryingtheserver’sISNplusoneinitsacknowledgementnumber eld.Aftercompletingthisexchange,aTCPconnectionisestablishedandboththeclientandservercansendandreceivedata.

Figure2.1:TCPconnectionestablishmenthandshake

ii

BothTCPandUDPuseportsforaddressingapplications.Aportissimplya16-bitinteger.Anyapplicationcanregisteritself(bind)toanyunusedporttosendorreceivedata,althoughsomecommonservicescustomarilyreceiveconnections(listen)onparticularports.Forinstance,SSH(“SecureShell”,usedforsecureremotelogins, letransfer,andtunnellingotherprotocols)serverstypicallylistenonport22/TCP,HTTP(usedforretrievingdocumentsfromwebservers)usesport80/TCP,andDNS(“DomainNameSystem”,responsibleformappingeasy-to-remembernamestonu-mericIPaddresses)serverslistenonport53/UDP.Unix-basedoperatingsystemstypicallyallowonlyprivilegedapplications(thosewithsuperuseroradministrativeprivileges)touseTCPandUDPportswithnumbersbelow1024.

Onmostoperatingsystems,applicationsusethesocketinterface[LFJ+86]tosendandreceivemessages.UnprivilegedapplicationsaretypicallylimitedtousingTCPandUDP;headers,withtheexceptionofaddressinginformation,areautomaticallygeneratedbytheoperatingsystem,asareTCPconnectionestablishmentand nal-izationmessages.Privilegedapplicationscanusetherawsocketinterfacetogeneratearbitrarypackets[LFJ+86].

NeitherIPv4,TCP,norUDPprovideanyauthenticationorprivacyservices;anyhostcangenerateanypacketandanyhostobservingpacketsatthenetworklayercanreadthepackets’payloads.Iftheseservicesareimportant,thentheycanbeprovidedbyapplication-layerprotocols,TCPextensionssuchasTLS[DR06],IPextensionssuchasIPsec[KS05],orthenext-generationInternetProtocol,IPv6[DH98].2.1.2

NetworkApplicationArchitectures

Applicationsthatcommunicateovernetworksusuallyfollowtheclient-servermodel:clientprograms,whichmayinterfacewithusers,connecttoserversandrequestre-sources.Forinstance,webbrowsersconnecttoserversandrequestdocuments,and

ii

SSHclientsconnecttoserversandrequestloginshells.Peer-to-peer(p2p)applicationsoperateasbothclientsandservers,allowingthemtoconnecttoeachother.Proxyserversactasintermediariesbetweenclientsandservers;clientsconnecttoproxies,whichthenconnecttoserversontheirbehalfandforwarddatabetweenthetwocon-nections.Suchsystemsareoftenusedfor rewalling(asincircuitandapplicationgateways;seeSection2.4.1),caching,andloadbalancing.2.1.3

VulnerabilitiesinInternetProtocols

WhenthecoreInternetprotocolsweredesigned,theInternetwasaresearchnet-workwithasmallusercommunitywhoknewandtrustedeachother.Asaresult,securitywasnotahighpriority.Manyprotocolshaveusefulfeaturesthateasilylendthemselvestomalicioususe;manyevenhaveoutrightdesign awsthatweakensecuritytonotangiblebene t.Forexample,

HostscanassertanysourceIPaddresstheywantonpacketsthattheygenerate(IPspoo ng).Routersoftenhavenowayofdeterminingifpackets’sourcead-dressesarecorrectandarenotrequiredtoblockinvalidpacketsevenwhentheycanbedetected.

EspeciallyinearlyTCPimplementations,theinitialsequencenumbersusedfornewconnectionswerepredictable;inconjunctionwithIPspoo ng,thisallowedattackerstoestablishTCPsessionswithremotehostswhileusingspoofedIPaddresses[Mor85].

ManyoftheprotocolsusedtodistributeroutinginformationontheInternetandmapphysicaladdressestoIPaddressesonlocalnetworksarenotsecure,allowingattackerstointercepttra cdestinedtootherhosts[Bel89,dVdVI98].

本文来源：https://www.bwwdw.com/article/r651.html