Firewallaufbau mit Linux - Linux-Praxis 1 Vorwort Die vorliegende Dokumentation beschreibt Funktionsweise, Aufbau und Wartung eines Firewallrechners unter Linux. Sie ist als begleitendes ...

  • Published on
    06-Feb-2018

  • View
    214

  • Download
    1

Transcript

CrashkursFirewallaufbauunterLinuxFlorianKalhammer21.Marz2001Inhaltsverzeichnis1 Vorwort 52 Grundlagen 62.1 DasOSI Referenzmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.1 Die Bitubertragungsschicht. . . . . . . . . . . . . . . . . . . . . . 72.1.2 Die Sicherungsschicht. . . . . . . . . . . . . . . . . . . . . . . . 72.1.3 Die Vermittlungsschicht . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Die Transportschicht. . . . . . . . . . . . . . . . . . . . . . . . . 82.1.5 Die Sitzungsschicht. . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.6 Die Darstellungsschicht . . . . . . . . . . . . . . . . . . . . . . . 92.1.7 Die Anwendungsschicht. . . . . . . . . . . . . . . . . . . . . . . 92.2 DasTCP/IPReferenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Die Vermittlungsschicht . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Die Transportschicht. . . . . . . . . . . . . . . . . . . . . . . . . 122.3 KommunikationsablaufeinerTCPVerbindung . . . . . . . . . . . . . . . 153 Grundlagen der Fir ewalltechnik 183.1 Die Voreinstellungfur Paketfilter . . . . . . . . . . . . . . . . . . . . . . . 203.2 REJECToderDENY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 Filter n von eingehendenPaketen 244.1 Filtern nachIPAdressen. . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.1 FilternnachAbsenderAdressen. . . . . . . . . . . . . . . . . . . 244.1.2 FilternnachEmpfangerAdressen. . . . . . . . . . . . . . . . . . 254.2 Filtern nachPortnummern . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.1 FilternnachderAbsenderPortnummer. . . . . . . . . . . . . . . 254.2.2 FilternnachderEmpfangerPortnummer . . . . . . . . . . . . . . 264.3 Filtern nachTCPStatusFlags. . . . . . . . . . . . . . . . . . . . . . . . 264.4 Angriffsformenvon auerhalb . . . . . . . . . . . . . . . . . . . . . . . . 264.4.1 Portscans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.2 DenialofServiceAttacks. . . . . . . . . . . . . . . . . . . . . 275 Filter n von ausgehendenPaketen 295.1 Filtern nachIPAdressen. . . . . . . . . . . . . . . . . . . . . . . . . . . 295.1.1 FilternnachAbsenderAdresse . . . . . . . . . . . . . . . . . . . 295.1.2 FilternnachEmpfangerAdresse. . . . . . . . . . . . . . . . . . . 295.2 Filtern nachPortnummern . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Filtern nachTCPStatusFlags. . . . . . . . . . . . . . . . . . . . . . . . 306 Gestaltungeiner Fir ewall mit Linux 316.1 Die drei StandardKetten . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 DasHandwerkszeug:ipchains . . . . . . . . . . . . . . . . . . . . . . . . 326.3 FormatderAngaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.3.1 IPAdressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332INHALTSVERZEICHNIS 36.3.2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4 PraktischerAufbaueinerFirewall . . . . . . . . . . . . . . . . . . . . . . 346.4.1 Grundeinstellungen. . . . . . . . . . . . . . . . . . . . . . . . . . 346.4.2 Ein paarTechnikenzur Abwehrvon gefalschtenPaketen . . . . . . 356.4.3 AusfilternoffensichtlichfalscherAdressen . . . . . . . . . . . . . 366.4.4 ICMPNachrichtenfiltern . . . . . . . . . . . . . . . . . . . . . . 396.4.5 DiensteaufunprivilegiertenPorts . . . . . . . . . . . . . . . . . . 416.4.6 WichtigeDiensteerlauben . . . . . . . . . . . . . . . . . . . . . . 427 Die Fir ewall alsRouter ins Inter net 467.1 RouteroderProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.1 Die ProxyTechnik . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.2 Die RouterTechnik . . . . . . . . . . . . . . . . . . . . . . . . . 477.2 DasProblemderreserviertenAdressen. . . . . . . . . . . . . . . . . . . . 487.3 MasqueradingalsProblemlosung. . . . . . . . . . . . . . . . . . . . . . . 497.4 VerschiedeneModellevon routendenFirewalls . . . . . . . . . . . . . . . 507.4.1 Die BastionHostFirewall . . . . . . . . . . . . . . . . . . . . . . 507.4.2 Die DemilitarisierteZone(DMZ) . . . . . . . . . . . . . . . . . . 518 ExemplarischerAufbau einer DMZFir ewall 538.1 Die symbolischenKonstanten . . . . . . . . . . . . . . . . . . . . . . . . 548.1.1 Die Konstantenfur die Bastion. . . . . . . . . . . . . . . . . . . . 548.1.2 Die Konstantenfur die Choke . . . . . . . . . . . . . . . . . . . . 558.2 WeitereGrundeinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . 558.3 ICMPNachrichtenfiltern . . . . . . . . . . . . . . . . . . . . . . . . . . 588.3.1 SourceQuenchNachrichten. . . . . . . . . . . . . . . . . . . . . 588.3.2 ParameterProblemNachrichten. . . . . . . . . . . . . . . . . . . 598.3.3 DestinationUnreachableNachrichten. . . . . . . . . . . . . . . . 598.3.4 TimeExceededNachrichten. . . . . . . . . . . . . . . . . . . . . 598.3.5 PingKonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 608.4 Diensteauf unprivilegiertenPorts . . . . . . . . . . . . . . . . . . . . . . 618.5 DomainNameService . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618.5.1 NutzungeinesoffentlichenNameservers . . . . . . . . . . . . . . 618.5.2 BetreibeneigenerNameserver . . . . . . . . . . . . . . . . . . . . 628.6 Der identService(auth) . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.6.1 KonfigurationderBastion . . . . . . . . . . . . . . . . . . . . . . 648.6.2 KonfigurationderChoke . . . . . . . . . . . . . . . . . . . . . . . 658.7 EMail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658.7.1 AbgehendeMails uberdieBastionverschicken . . . . . . . . . . . 658.7.2 MailempfanguberPOPServeraufderBastion . . . . . . . . . . . 668.8 Alle weiterenDienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.9 LAN Zugriff auf dieChoke . . . . . . . . . . . . . . . . . . . . . . . . . . 678.10 Und schlielichdasMasquerading. . . . . . . . . . . . . . . . . . . . . . 68A Wichtige Portnummern 69A.1 HaufiggescanntePorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.2 ICMP NachrichtenTypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B Die BeispielScripts 72B.1 DasersteFirewallscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72B.2 DasBastionFirewallscript . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.3 DasChokeFirewallscript . . . . . . . . . . . . . . . . . . . . . . . . . . . 864 INHALTSVERZEICHNISC Protokollbeschreibungen 90C.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91C.2 identdoderauth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92C.3 UsenetNews (NNTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92C.4 E-Mail (SMTP/POP/IMAP) . . . . . . . . . . . . . . . . . . . . . . . . . 93C.5 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94C.6 SecureShell(SSH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94C.7 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95C.8 HTTP - Normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.9 HTTP - mit SecureSocketLayer(SSL) . . . . . . . . . . . . . . . . . . . 96C.10 HTTP-ProxyZugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Kapitel 1VorwortDie vorliegendeDokumentationbeschreibtFunktionsweise,Aufbau und WartungeinesFirewallrechnersunterLinux. Sie ist alsbegleitendesMaterial fur eineSchulunggedacht,nicht als SelbststudiumHilfe.DasThemaFirewall ist ein weit gefacherterBereich,derhier nicht abschlieendbehandeltwerdenkann,es sollen die in der Schulungund demAufbauvorkommendenPunktebesprochenunddargestelltwerden.EineFirewall ist ein Sicherheitssystem,das wie alle anderenSicherheitssystemeauchim Idealfall nichtgenutztwerdenmu,weil z.B.keinAngriff aufdasComputersystemvor-liegt. Wie aberbei Sicherheitssystemenublich,nutzt unsdiesesSystemnur dann,wennesim Bedarfsfall perfektfunktioniert.Fur dieseGarantiederperfektenFunktionist abereineSachewesentlicheVoraussetzung:DasVerstandnisder zugrundeliegendenTechnologie.DiesesVerstandniskannbeivielenMenschen,diemit Computernzwarzutunhaben,dieseabernicht restlosverstehen,nicht vorausgesetztwerden.Aus diesemGrundbeginnt dieseBeschreibungmit einemKapitel Netzwerkgrundlagen,die fur viele vielleicht ubertriebengenauerscheint.Trotzdemmu damitspaterdieFunktionsweisederFirewall hinlanglichsicheraufgebautwerdenkann diesesWissenvorhandensein.. .Die BeschreibungderTechnikenbeziehtsichhierauf einLinuxSystemmit einemKernelderVersionen2.2.x,dermit ipchainsarbeitet.In denfruherenVersionenwurdestattdieserTechnikein Programmmit Namenipfwadmeingesetzt,in derallerneuestenKernelversion(2.4)wird eineneueTechnik(iptables) verwendet.In Sicherheitstechnikensolltenaberim-merausgereifteunderprobteWerkzeugezumEinsatzkommen.Daherscheintmir ipchainsdie besteLosungdarzustellen.Der Umstieg auf die neueTechnikist im wesentlichenauchnureinsyntaktischer, die Regelnbleibengrotenteilsdieselben.DieseDokumentationkanneinesnicht sein,eineEinfuhrungin bzw. ein Lehrgangfur Li-nux selbst.Eswerdenhier alsowederdie Installation,nochdie grundlegendenTechnikendesUmgangsmit Linux beschrieben.Eine StandaloneFirewall mit Linux bedarfaller-dingsauchnicht einergroenVerwaltungsarbeit,sodaein durchschnittlichesWissenumLinux sicherausreichendist, um die hier beschriebenenVorgangenachzuvollziehenundreproduzierenzu konnen.Wo immer esnotwendigist, genaueAngabenzu machen,wobzw. wie etwasin Linux einzustellenist, wird esausreichendbeschrieben.Daim vorliegendenFall dieLinuxDistributionderS.u.S.EGmbHeingesetztwird (S.u.S.E7.0 Professional),bezieheich mich im wesentlichenauchauf die in dieserDistributionublichenDateienundVerzeichnisse.Im GroenundGanzensolltenaberalle Technikenmit kleinenAnderungen auchin jederanderenmodernenLinuxDistribution implemen-tierbarsein.Die Unterschiedewerdensichim Wesentlichenauf verschiedeneStartdateienreduzieren,in denendieentsprechendenFirewallRegelneingetragenwerden.DieseStart-dateiensind in fastjederDistribution unterschiedlich,daherwurdeeineallgemeingultigeBeschreibungdenRahmendieserDokumentationsichersprengen.5Kapitel 2GrundlagenDer Begriff Firewall hatkeineeindeutigeDefinition undkeinestandardisierteBedeutung.EshandeltsichvielmehrumeinModell zurAbsicherungeinesComputernetzesgegenuberanderen meistoffentlichen Netzen.Im RahmendieserAnforderungkommen je nachGroeundKonzeptdeszuschutzendenNetzes verschiedeneLosungsansatzein Frage.InjedemFall mudiegewunschteSicherheitin verschiedenenSchichtenangegangenwerden,eineinzigerMechanismus,wie etwanur einePaketFirewall alleineist niegenug.Im Allgemeinenwird beim ThemaFirewall zwischendem zu schutzendenNetz (inter-nesLAN oder auchsicheres Netz) und dem offentlichenNetz (meist das InternetoderauchunsicheresNetz) unterschieden.Im einfachstenFall ist die Firewall hier ein physi-kalischerRechner, der mit zwei Netzwerkverbindungen(Netzwerkkarten,ISDN-Karten,Modems,.. . ) ausgestattetist. Eine davon ist mit demsicheren,die anderemit demunsi-cherenNetzverbunden.Der einzigeWeg, derbeideNetzeverbindet,ist ebendieFirewall.Auf diesemVerbindungsrechnerwerdennun Strategien implementiert,die die Sicherheitdeszu schutzendenNetzes aberauchdie Regeln,die beschreiben,wer im sicherenNetzwasim unsicherenNetzmachendarf festlegen.Dazuzahleninsbesondere: WelcheInternetDienstedurfenvomlokalenNetzausgenutztwerden? WelcheDienstedarfdieganzeWelt in Anspruchnehmen? WelcheDienstedurfenausgewahlteBenutzeroderComputerin Anspruchnehmen? WelcheDienstedurfennur lokal genutztwerden?DergrundlegendeAnsatzzurImplementierungdieserStrategienistdiesogenanntePaketfilterFirewall. Im weiterenVerlaufdieserDarstellungwird esalsohauptsachlichum die Kon-zeptionund Wartungeiner solchenPaketfilterFirewall gehen,implementiertmit einemLinuxSystem.Linux bietet fur dieseAufgabealle notwendigenWerkzeugebereitsimBetriebssystemKern,es ist alsonicht notwendig,komplizierteZusatzinstallationenvor-zunehmen,dieeinSystemnur instabilerwerdenlassen.Auf deranderenSeitewurdeja schonerwahnt,daeinehinreichendeSicherheitnur uberverschiedene,aufeinanderaufbauendeMechanismenherzustellenist.Auchfurdiesehoher-gelegenenSicherheitsstufensindunterLinux alleWerkzeugebereitsin derStandardInstallationvorhanden.Zunachstgilt unserAugenmerkjedochdenMechanismendesPaketfilterns.UmgrundsatzlichdiesenVorgangverstehenzukonnen,ist esnotwendigeinpaargrundlegendeBegriffe undTechnikenderComputervernetzungzu beschreiben.Wasist uberhauptKom-munikationin Netzwerken,wie lauft sieabundwelcheMittel desEingreifensstehenunsalsozurVerfugung?2.1 DasOSI ReferenzmodellEndedersiebzigerJahrewurdeein theoretischesReferenzmodellfur die VernetzungvonComputernentworfen,dasauchheutenochvielen Darstellungenzugrundeliegt. Es han-62.1. DAS OSIREFERENZMODELL 7delt sich dabeium dassogenannteOSIReferenzmodell.OSI stehtfur OpenSystemIn-terconnection, alsoetwa VerbindungoffenerSystemeuntereinander. DiesesModell ist einSchichtenmodellmit siebenSchichten,die die KommunikationderComputeruntereinan-derbeschreiben.Esist sehrakademischangelegt undwurdevonkeinemrealexistierendenNetzwerksystemvollstandigimplementiert.Trotzdemwird eszurDarstellungderverschie-denenMechanismennochheutebenutzt.Daherfolgt hier einekurzeBeschreibungdiesesModells:Anwendungsschicht (application layer)Sitzungsschicht (session layer)Transportschicht (transport layer)Verbindungsschicht (network layer)Sicherungsschicht (data link layer)Bituebertragungsschicht (physical layer)Darstellungsschicht (presentation layer)Bild 2.1: DasOSI-ReferenzmodellDie beidenunterstenSchichtensind im FalleeinerherkommlichenNetzverbindungetwauber EthernetKarten auf der Netzwerkkarteselbstimplementiert.Sie sind also nichtBestandteilderSoftwareoderdesBetriebssystems.Von untennachobenbetrachtetkommendenverschiedenenSchichtendie folgendenAuf-gabenzu:2.1.1 Die Bit ubertragungsschichtDie Bitubertragungsschicht(physicalLayer)ist verantwortlich fur dieUbertragungderein-zelnenBits,siehatalsoeinfachdieAufgabedafur zusorgen,dawo eine1 gesendetwurdeaucheine1 empfangenwird undwo eine0 gesendetwurdeebeneine0 empfangenwird.TypischeFragendieserSchichtsinddieSpannungen,diejeweilseiner1 oder0 entsprechenundwielangedieseSpannungenaufrechterhaltenwerdenmussen,damitein Bit gesendetwird. DieseSchichtist immer direkt mit der Hardwareverbunden,ihre KonstruktionistalsoAufgabedesHardwareherstellers.2.1.2 Die SicherungsschichtDie Sicherungsschicht(datalink layer) verarbeitetdie ubertragenenRohdatenindemsieeineDatenreihedarauserstellt und dieseDatenreihegewohnlichermaenin einensoge-nanntenDatenubertragungsrahmen(dataframe)packt.Die Sicherungsschichtkommuni-ziert mit ihrer gegenuberliegendenSicherungsschichtdurchsogenannteQuittungsrahmen,diekorrektverarbeitetwerdenmussen.8 KAPITEL 2. GRUNDLAGENUm dasGanzeeinmal im Detail zu sehenfolgt hier die Darstellungder FramestruktureinesDatenrahmens(engl.frame)derIEEE802.3Norm,alsoderNorm,dieunserEthernetbenutzt:Prambel Zieladresse Quelladresse Da ten PadDatenfeldesdesBeginn des RahmenbegrenzersBytes 7 1 6 6 2 01500 046 4Laenge PruefsummeBild 2.2: Das802.3FrameformatDie beidenAdressfelderenthaltendabeidie Hardwareadresse(MACAdresse)der jewei-ligen Netzwerkkarten.DasDatenfeldenthalt die eigentlichenDaten,falls eswenigerals46 Byte sind, so wird dasPadFeldbenutztum die (physikalischnotwendigen)46 Byteaufzufullen.Die Prufsummeist schlielicheineMoglichkeit, Fehlerbei derUbermittlungdirekt zu erkennenundein fehlerhaftesPaketgegebenenfallsnochmalanzufordern.2.1.3 Die VermittlungsschichtDieseSchicht(Network Layer)steuertdieverschiedenenTransportwegeinnerhalbdesNet-zes.In kleinenLAN ist dieseSchichtalsoverhaltnismaigdunn, in groenNetzen(z.B.demInternet)hatsiesehrumfangreicheAufgaben.Die WahlderverschiedenenmoglichenRoutenvomSenderzumEmpfanger, dasoptimaleAusnutzenderbestehendenVerbindun-genundahnlichessindihre Aufgaben.2.1.4 Die TransportschichtDie Aufgabeder Transportschicht(TransportLayer) ist es,denDatenstromvon der Sit-zungsschichtzurVermittlungsschichtweiterzugeben,eventuellin kleinerePaketezupackenund dafur zu sorgen,daalle Teile in der korrektenReihenfolgeankommen.Die Trans-portschichtbauteinedirekteKommunikationzwischenSenderund Empfangerauf, undarbeitetmit einementsprechendendirektenProtokoll. Man sprichthier von einerEnde-zu-EndeSchicht,im GegensatzdazuwarendiebisherbesprochenenSchichtensogenanntegeketteteSchichten.Dasheit,dasienichtunbedingteinedirekteKommunikationmit derZielmaschinebetrieben,sondernnur mit denzwischenSenderund EmpfangerliegendenZwischenstationen(Gateways,Bridges,...)Viele Computerarbeitenheuteim Multitasking-Betrieb,eskannalsosein,dazwischenzwei RechnernmehrereunabhangigeNetzwerkverbindungenbestehen.Auch die Koordi-nationdieserTatsacheist AufgabederTransportschicht.2.1.5 Die SitzungsschichtDie Sitzungsschicht(SessionLayer) hat ahnlicheAufgabenwie die Transportschicht,je-dochin eineretwasgehobenerenForm. SiemuzumBeispielabgebrocheneTransferver-suchean der Stellewiederaufnehmen,an der sie abgebrochenwurden.Insgesamtkonntemanesdamitzusammenfassen,dadieSitzungsschichtzustandigfur dieDialogsteuerungist.2.2. DAS TCP/IPREFERENZMODELL 92.1.6 Die DarstellungsschichtDie Darstellungsschicht(PresentationLayer)ist zustandigfur diekorrekteDarstellungderDaten.DieseSchichtwird z.B. dadurchnotwendig,daverschiedeneComputerverschie-deneFormenderDarstellungfur Ganz-undKommazahlenhaben.Esgibt etwa die soge-nanntenBig-EndianSysteme,die in einer16-Bit GanzzahldashoherwertigeByte zuerstanfuhren,wahrenddie Little-Endian Systemees genauandersherummachen.WurdenComputermiteinanderkommunizieren,die dieseDarstellungunterschiedlichhandhaben,sokamenzwar GanzzahlenamZielrechneran,er wurdesieaberganzlichfalschinterpre-tieren.2.1.7 Die AnwendungsschichtDie letzteSchichtdesOSI-Modells(ApplicationLayer)enthalt nundieverschiedenenAn-wendungen,diesichgegenseitiguberdasNetzverstandigen.DieseSchichtist in derRegeldirekt in dasAnwenderprogrammprogrammiertundenthalt die jeweiligenProtokolle, mitdenendieProgrammekommunizieren.2.2 DasTCP/IP ReferenzmodellNachdemdasOSI-ModelleineherakademischesModell ist undvonkeinerNetzwerksoft-warewirklich hundertprozentigimplementiertwird, ist esjetzt anderZeit, dasModell zubetrachten,dastatsachlichheuteim Internet(undallen lokalenNetzsystemen)verwendetwird, TCP/IP. Im GegensatzzumOSI-Modell kommtTCP/IPmit nur vier Schichtenaus,um denDatentransferzuerklaren:NetzzugriffsschichtInternetSchichtTransportschichtAnwendungsschichtBild 2.3: DasTCP/IP-SchichtenmodellDiesevier Schichtenkommunizierennicht genaumit denendesOSIModells,vereinfachtkann man sagen,dadie Netzzugriffsschichtdie beidenunterstenSchichtendesOSIModellsenthalten,die InternetschichtentsprichtgenauderVermittlungsschicht,dieTrans-portschichtvon TCP/IP erfullt im Wesentlichendie Aufgabender TransportschichtdesOSI-Modellsund die restlichendrei Schichtenvon OSI sind in der Anwendungsschichtvon TCP/IPintegriert.Auf all diesenvier SchichtenarbeitenunterschiedlicheProtokolle zur Datenubertragung.Vereinfachtkonntedasetwawie folgt dargestelltwerden:10 KAPITEL 2. GRUNDLAGEN802.3, PPP, SLIP, ...IPUDPTCPFTP HTTP SMTP TELNET ...ICMPAnwendungTransportVermittlungNetzzugriffBild 2.4: Protokolle desTCP/IP-SchichtenmodellsIn derAnwendungsschichtarbeitenalsosehrviele verschiedeneProtokolle, in derTrans-portschichtgeradenochzwei, in derVermittlungsschichtnur einesundauchauf derNetz-zugriffsschichteines(allerdingseinesausvielenmoglichen).JedeSchichtdiesesModells muInformationenbesitzen,an welcheAbteilung der uberihr liegendenSchichtsiedenDatenstrombeimEmpfangweitergebensoll. Von untennachobenbetrachtetergibt sichdamitfolgenderVorgang: Die Netzzugriffsschichtbekommtein PaketausdemNetz.Siehatkein ProblemmitderWeitergabe,denndie uberihr liegendeSchichtenthalt nurein Protokoll, IP. DasInternetProtokoll (IP) derVermittlungsschichtmuaufgrundder ihr ubermit-teltenInformationschonentscheiden,wem siedasPaket weitergibt. EsstehenhierdreiMoglichkeitenzurAuswahl: DasPaketbleibt in derVermittlingsschichtundwird vomInternetControlMes-sageProtocol(ICMP) weiterverarbeitet(z.B.ping) DasPaket Gehort zu einemTCPDatenstromund mu an dasTransmissionControlProtocol(TCP)derTransportschichtweitergeleitetwerden. DasPaket enthalt ein UDP-Datagramund mudaheran dasUserDatagramProtocol(UDP)derTransportschichtweitergegebenwerden.DieseInformation mu IP ausdem IPDatagramHeadergewinnen. Das FormatdiesesHeadersist weiteruntenerklart. Die ProtokollederTransportschicht(TCPundUDP)habendiegroteAufgabe,dennsiemussenauseinerVielzahlvon moglichenAnwendungenauswahlen,fur welchedieserAnwendungendasempfangenePaket ist, alsoanwelcheAnwendungsiedieDatenweiterleiten.Zu diesemZweck besitzt jede Anwendungder Anwendungs-schichteine Kennummer, die sogenanntePortnummer. DieseNummerlegt genaufest,welcheAnwendungdasPaketerhalt.Die beidenSchichten,die unsjetzt genauerinteressieren,sinddie mittleren,alsovermitt-lungsschichtundTransportschicht.Hier findendieMechanismenstatt,diefur dasVerstand-nis einerFirewall unerlasslichsind.2.2. DAS TCP/IPREFERENZMODELL 112.2.1 Die VermittlungsschichtAuf der Vermittlungsschicht(InternetSchicht)von TCP/IParbeitetim Wesentlichennurein Protokoll, dasIP (InternetProtocol).DiesesProtokoll arbeitetnicht mit den physi-kalischenAdressenvon Netzwerkkarten,sondernmit logischenAdressen,ebendenall-seitsbekanntenIPAdressen.DieseSchichtfugt deneigentlichzu ubermittelndenDatennochVerwaltungsinformationenhinzu.DiesesFormatwird alsDatagramFormatbezeich-netundhatdie folgendeStruktur:0 4 8 12 16 20 24 28 31BitsFlags FragmentOffsetVersion IHL Diensttyp GesamtlaengeKennungLebensdauer Protokoll KopfPruefsummeSender IP AdresseOptionen FuellzeichenEmpfaenger IP AdresseAb hier kommen die Daten...HeaderBild 2.5: DasIPDatagramFormatDie BedeutungdereinzelnenFelderistVersion Ein vier Bit breitesFeld,dadieVersionsnummervon IP enthalt. Im Augenblickwird hier meisteine4 stehen,in derneuenVersionIPV6 folgerichtigdanneine6.IHL InternetHeaderLength 4 Bit. Gibt die LangedesHeadersin 32 Bit Worten an.Damit kannermittelt werden,ob Optionengesetztsind.Normalerweise(ohneOp-tionen)hatdiesesFelddenWert 5.Diensttyp TOS(Typeof Service)- 8 Bit. Enthalt Flags,diezurSteuerungderZuverlassig-keit desNetzesdienen.Siewerdenautomatischerstellt.Gesamtlange Enthalt die GesamtlangedesDatagramms(incl. Kopf) in Byte. Aus derBreitediesesFeldes(16 Bit) ergibt sichsoeinemaximaleGroevon Datagrammenvon 65535Byte. DieserWert liegt weit uber dem maximalenWert der einzelnenNetzsysteme,daherreichen16Bit aus.Kennung JedesIP-DatagrammmueineeigeneKennunghaben,um beimWiederzusam-menbaurichtig eingeordnetzu werden.Flags Ein DreiBitFelddasFlagszur SteuerungderFragmentierungenthalt.Lebensdauer In Netzenwie demInternet,in denenvieleDatagrammeaufunterschiedlch-stenWegenversuchenzumZiel zukommen,mueinemaximaleLebensdauerhaben,sonstwerdensieunendlichoft geroutet.DiesesFeldenthalt eineZahl,dievom Sen-dereingetragenwurde.JederGatewaymudieseZahlumeinsherunterzahlen,wennereinDatagrammroutet.Ist derWertNull, sodarfkeinRouterdasDatagrammmehrweiterleiten.UblicheStartwertesind32 oder4 (nur lokaleNetzesetzensoniedrigeLebensdaueran)12 KAPITEL 2. GRUNDLAGENProtokoll DiesesFeld gibt an, von welchemProtokoll der TransportschichtdiesesDa-tagrammkommt.Dasist wichtig fur denEmpfanger, weil auf derTransportschichtmehrereProtokolle arbeitenbzw. esauchPaketegibt, diegarnichtbiszurTransport-schichtweitergeleitetwerdensollen.NurdurchdieseInformationkanndasEmpfangerIP dasDatagramman dasrichtige Transportschichtprotokoll weiterleiten.UblicheWertesind: 17 UDP 6 TCP 1 ICMPKopfPrufsumme PrufsummeuberdenInhalt desHeaders,nicht der Daten.Die Uber-prufungderDatenwird von derTransportschichterledigt.SenderIPAdr esse32Bit IP-AdressedesSendersEmpfanger IPAdr esse32 Bit IP-AdressedesEmpfangersOptionen Hier konnenverschiedeneOptionengesetztwerden,die mit Debugging(Feh-lersuche)oderRoutenprufungzu tun haben.Fullzeichen Fullt denBereichzwischendenjeweilsgesetztenOptionenunddemEndedes32Bit Wortesauf.DasInter net Controll MessageProtocol (ICMP)Das InternetControl Message Protocol (ICMP) ist ein integralerBestandteilvon IP unddientzur UbermittlungtechnischerMeldungen,die ubersNetzgehen,abernicht uberdieIP-Schichthinauskommenmussen.D.h., dadiesesProtokoll in der Lage ist, Paketezuschicken,die nicht anein Transportprotokoll derTransportschichtgebundensind,sondernebennurvon Vermittlungsschichtzu Vermittlungsschichtgehen.Die Aufgaben,diediesesProtokoll zuerfullenhatsindhier kurz aufgelistet:Flukontrolle Wennein RechnerDatagrammesoschnellschickt,daderEmpfangersienicht rechtzeitigverarbeitenkann,so schicktder EmpfangeruberICMP eineMel-dungan denSender, dadie Sendungenvorubergehendstoppensollen.NachdemderEmpfangeralle anstehendenDatagrammeverarbeitethat,schickter erneuteineMeldung,daer wiederempfangsbereitist.Erk ennenvon unerreichbarenZielr echnern WenneinGatewayerkennt,daeinbestimm-ter Rechnernicht erreichbarist, soschickter andenAbsenderdesPaketeseineDe-stinationunreachableMeldunguberICMPRoutenoptimierung WenneinGatewayerkennt,daereinenUmweg darstellt,soschickter an denAbsendereineMeldung,in derdie schnellereRoutesteht.Der Absender(bzw. seineIP-Schicht)kanndanndasnachstePaket schonuberdenbesserenWegubermitteln.Uberpr ufen von erreichbarenHosts Mit Hilfe desICMP Echo Message kannein Rech-neruberprufenob ein Empfangeransprechbarist. DaspingKommandonutztdieseEcho-Meldung.2.2.2 Die TransportschichtAuf der Transportschichtvon TCP/IP arbeitenzwei verschiedeneProtokolle, TCP undUDP. DerwesentlicheUnterschiedzwischendenbeidenProtokollenist dieFragederKom-munikationssteuerung.TCP (TransmissionControl Protocol)arbeitetverbindungsorien-tiert, esbautalsoeinenDatenstromzwischenEmpfangerundSenderauf,derubermehrerePaketeverteilt ist und dessenkorrekterEmpfangpermanentdurchQuittungspaketevom2.2. DAS TCP/IPREFERENZMODELL 13Empfangerbestatigtwerdenmu.Im GegensatzdazuarbeitetUDP(UserDatagramProto-col) verbindungslos, dasheit,eswerdeneinfachPakete(Datagramme)vom SenderzumEmpfangergeschickt,ohnedadieserdenEmpfangquittierenmu.BeideProtokolle arbeitenwiedermit einemsogenanntenHeader, derdemeigentlichenDa-tenpaketvorangestelltwird. BeidenHeaderformenist einsgemeinsam,sieenthalteneinenEintragfur die PortnummerdesSenderprozessesunddie desEmpfangerprozesses.DiesePortnummernwerdenunsim nachstenAbschnittnochgenauerbeschaftigen.Im folgendenwerdenbeideHeaderformatekurz dargestellt:DasUDPMessageFormatDie interneStrukturdesUDPHeadersist sehreinfach.Als datagramorientiertes(verbin-dungsloses)Protokoll benotigt UDP keinerleiInformationenuberSequenznummernoderahnliches,derbenotigteHeaderist alsosehrklein:QuellPortnummer ZielPortnummerLaengeAb hier DatenBits0 16 31PruefsummeBild 2.6: DasUDPMessageFormatDie BedeutungdereinzelnenFelderistQuellportnummer bezeichnetdiePortnummerdesAnwenderschichtprogrammes,vondemdieUDP-Messageabgeschicktwurde.Zielportnummer bezeichnetdie PortnummerdesEmpfangerprogrammsauf derAnwen-dungsschicht.Lange Hier stehtdieLangedergesamtenUDP-Message(incl. Header)Prufsumme EinePrufsummeuberdasDatenfeldUDP wird uberalldort verwendet,wo entwederdie Datenmengeso klein ist, daessichnicht lohnenwurde,einengroenHeaderzu benutzen,weil der groerals die eigentli-chenDatenwareoderwo die AnwendungenselbstnochUberprufungendesPaketinhaltesvornehmen.Lohnenswertist der Einsatzauchdort, wo reineFrage-Antwort Mechanismenauftreten.Dort ist kein verbindungsorientiertesProtokoll notig, weil ja nachdemSendeneinerFra-ge klar ist, wenn nacheiner bestimmtenZeit keine Antwort eingeht,so wird dasPaketverlorengegangenseinunddie Fragemunochmalgestelltwerden.DasTCPSegmentFormatTCPist im GegensatzzuUDPeinverbindungsorientiertesProtokoll, dasDatenstromever-arbeitet,die von der Anwendungsschichtkommen.TCP garantiertdie VersendungvonDatendurcheingebauteHandshake-Mechanismen.14 KAPITEL 2. GRUNDLAGENTCP bieteteinenverlasslichenDatentransferdurchdie VerwendungeinesMechanismus,derDatenpakete(sogenannteSegmente)aneinenEmpfangerschicktundauf eineBestati-gungdesEmpfangsseitensdesEmpfangerswartet.Dabeiuberpruft der EmpfangerauchwiedermittelseinerPrufsumme,obdasPaket fehlerfreiangekommenist.DasFormatdesHeadersist zwangslaufigalsowesentlichkomplexeralsdasvon UDP:0 4 8 12 16 20 24 28 31BitsOptionenAb hier kommen die Daten...HeaderAbsender PortnummerSequenznummerReserviert Flags FensterDringlichkeitszeigerOffsetFuellzeichenPruefsummeBestaetigungsnummerEmpfaenger PortnummerBild 2.7: DasTCPSegmentFormatDie BedeutungdereinzelnenFelderistAbsenderPortnummer bezeichnetdiePortnummerdesAnwenderschichtprogramms,vondemderDatenstromabgeschicktwurde.Empfanger Portnummer bezeichnetdie PortnummerdesEmpfangerprogrammsauf derAnwendungsschicht.SequenznummerGibt die Positionim Datenstroman, an der diesesSegmenteingefugtwerdensoll.Bestatigungsnummer Dient zur BestatigungdesEmpfangseinesSegments.DiesesFeldenthalt immer die Nummer, die im nachstenSegmentals Sequenznummerstehensoll.Daten-Offset Gibt die GroedesHeadersin 32 Bit Wortenan.OhneOptionensindes5.Damit kanngenaubestimmtweden,wo derDatenbereichdesSegmentsbeginnt.Flags VerschiedeneFlagszurKommunikationssteuerung(SYN,ACK,.. . )Fenster Mit diesemWertwird dieGroedesBuffersangezeigt,dervoneinemEndknotenfur dieseVerbindungreserviertwurde.Der sendendeKnotendarf keinesfalls mehrDatenals die angegebenePuffergroesenden,ohneauf denEingangeinerBestati-gungzuwarten.Prufsumme EinePrufsummeuberdasgesamteSegment(DatenundHeader)Dringlichk eitszeiger Wird beibesondersdringendzuverarbeitendenPaketengesetzt.Wenngesetztenthalt diesesFeldalsWertdieEndadressedesDatenfeldes,dasalsdringlichgilt2.3. KOMMUNIKATIONSABLAUF EINERTCPVERBINDUNG 15Optionen VerschiedeneOptionenzur Kommunikationwie etwa die maximaleSegment-groeFullzeichen Zum AuffullenderOptionszeileauf32 Bit2.3 Kommunikationsablauf einer TCPVerbindungDie meistenNetzwerkdiensteim Internetarbeitenmit TCP als Transportprotokoll. AusdiesemGrundsoll hiereinmaldetailliertderKommunikationsablaufeinertypischenTCPVerbindungbeschriebenwerden.DasVerstandnisdiesesAblaufsmachtunsspaterdasEin-richteneinerFirewall erheblichleichterundvermeidetFehler, diesonstauftretenkonnten.EinetypischeVerbindungmit TCPwaredie KommunikationeinesWebBrowsersmit ei-nemWebserveruberdasHypertextTransferProtocol(HTTP).DiePortnummerdesWebser-versist standardmaigdie80,derWeb-Client(alsoderBrowser)nimmtsicheinebeliebigefreiePortnummerabder1024.In unseremBeispielwird esdiePortnummer12345sein.Der ersteSchritt der KommunikationzwischenWebClientund Webserver bestehtdar-in, dader BenutzerdesClients eine Adressein den Browser also den Client ein-gibt. DieseAdressewird in eineIPAdresseumgewandeltund der Client bekommtvomBetriebssystemeinenfreien Port oberhalb1024(alsoeinensogenanntenunprivilegiertenPort) zugewiesen.In unseremBeispielist dasderPort12345.Mun schicktjetzt derClientein HTTPPaket andenServer. Die Transportschichtund ihr Protokoll TCPerkennt,daessich um eineneueVerbindunghandeltund setztdassogenannteSYNFlag im FlagBereichdesTCPSegmentHeaders.Webserverbenutzen sofernnichtandersangegeben standardmaigdenPort80.Esergibt sichalsofolgendesBild:WebServerWorkstation mit BrowserIPAdr.: 123.45.67.89 IPAdr.: 10.11.12.13Port 12345 Port 80Protokoll: TCPAbsenderIP: 123.45.67.89AbsenderPort: 12345EmpfaengerIP: 10.11.12.13EmpfaengerPort: 80Flags: SYN (Aufforderung zur Verbindungssynchronisation) Bild 2.8: Client bittet umVerbindungsaufbauDer Client schicktin demHeadernebendemSYNFlag alsoder Bitte um Verbindung aucheineSequenznummer. Auf derBasisdieserNummerwird die weitereVerbindungabgewickelt.DasabgeschicktePaket kommt jetzt auf demServer anundgelangtbis zur Anwendungs-schichtunddort zumPort80.Dort nimmt ein Serverprogramm(hier derWebserverhttpd)denDatenstromentgegen.Der Server erkenntaufgrunddesSYNFlags,daessich umeineneueVerbindunghandeltund reservierteinenneuenSocket fur die Kommunikation16 KAPITEL 2. GRUNDLAGENmit demClient.Er schicktjetzteinPaketzuruck,dassowohl dasACKFlag(Acknowledge Bestatigung),alsauchwiederumein SYNFlaggesetzthat.Man sprichtjetzt von einerhalboffenenVerbindung.WebServerWorkstation mit BrowserIPAdr.: 123.45.67.89 IPAdr.: 10.11.12.13Port 12345 Port 80Protokoll: TCPAbsenderIP: 10.11.12.13AbsenderPort: 80EmpfaengerIP: 123.45.67.89EmpfaengerPort: 12345Flags: ACK (Bestaetigung der Anfrage)SYN ( Aufforderung zur Verbindungssynchronisation) Bild 2.9: BestatigungderBitte um VerbindungsaufbauDie SequenznummerdesPaketes,dasderServer in Bild 2.9 demClient zuruckschicktistdieSequenznummerdeserstenPaketespluseins.DamitbestatigtderServerdenErhaltdesletztenPaketesundmachtgleichzeitigklar, welcheSequenznummerer im nachstenPaketerwartet.Damit kannderClient daserstePaket jetzt wegwerfen,daer denErhalt ja jetztbestatigtbekommenhat.DieseersteAntwort vomServerhatbeideFlags(ACK undSYN) gesetzt.VonnunanwirddergesamteDatenverkehrimmernurnochmit demACKFlagablaufen.Die Tatsache,dain allen PaketendesServersdasACKFlaggesetztist, in der erstenAnfragedesClientsjedochnicht,wird beimAufbaueinerFirewall ein wichtigesKriterium sein.Im nachstenSchrittbestatigt derClient seinerseitsdenEmpfangderAntwort desServers.Von nunanwird nur nochdasACKFlaggesetztsein.WederServer, nochClient werdenim Lauf derVerbindungdasSYNFlagnochmalbenutzen.2.3. KOMMUNIKATIONSABLAUF EINERTCPVERBINDUNG 17WebServerWorkstation mit BrowserIPAdr.: 123.45.67.89 IPAdr.: 10.11.12.13Port 12345 Port 80Protokoll: TCPAbsenderIP: 123.45.67.89AbsenderPort: 12345EmpfaengerIP: 10.11.12.13EmpfaengerPort: 80Flags: ACK (Bestaetigung) Bild 2.10: Die Verbindungist hergestelltBei jederweiterenBestatigung(alsojedemweitererhaltenenACKFlag)erhohensowohlClient, als auch Server die Sequenznummerndes letztenempfangenenPaketes.DamitbestatigensiealsodenEmpfangdesPaketesundgebengleichzeitigbekannt,welchesPa-ketsiealsnachsteserwarten.Die jeweiligeGegenseitekannalsoallePaketemit nierigerenSequenznummernwegwerfen.Um eineVerbindungabzubauenwird ein weiteresFlagbenutzt,dasaberfur denAufbauvon Firewallsystemenunwichtigist. Zusammenfassendkonnenwir alsofesthalten:DasSYNFlagist gesetzt,wennClient und Server jeweils ihr erstesPaket schicken.Beiallen folgendenPaketenist dasACKFlaggesetzt.Ein Paket, in demnur dasSYNFlaggesetztist muzwangslaufigeineAnfrageeinesClientsaneinenServersein.Nachdemnundie GrundlagenderTCP/IPKommunikationgeklartsind,ist esanderZeit,dieGrundlagenderFirewallTechnikenanzusprechen.Die in diesemKapitelbesprochenenFelderderTCPundIPHeaderwerdendabeiKriterien fur dieAuswahl sein.Kapitel 3Grundlagen der Fir ewalltechnikDie hier vorgestellteFirewall ist einesogenanntePaketfilterFirewall. Dabeigehtesalsodarum,die im letztenKapitel angesprochenenPaketezu bewertenundanhandverschiede-nerKriterienzuentscheiden,ob einPaketpassierendarf,odernicht.Eine solchePaketfilterFirewall arbeitetin der von unsbesprochenenLinuxVersionmiteinerListevonAnnahmeoderAblehnungskriterien.DarausentstehensogenannteRegeln,diegenaubestimmen,ob einPaketpassierendarfodernicht.DieseKriteriensind Netzwerkschnittstelle IPAdressen TCP/UDPPortnummernbzw. ICMP Nachrichtentypen SYNundACKFlags Die Flurichtung(eingehendesoderabgehendesPaket)All dieseInformationenzeigen,dadieFirewall alsoaufderVermittlungsund Transport-schichtdesTCP/IPSchichtenmodellsarbeitet.Fur beideFlurichtungen(ankommend Input undabgehend Output)stehenjeweils ei-geneFilter zur Verfugung.Der grundlegendeMechanismusist dabeider, dafur beideRichtungeneineganzeAnzahlvon hintereinanderfolgendenRegelnexistieren,die hinter-einanderabgearbeitetwerden.So entstehtebeneinesogenannteKette (engl. chain) vonRegeln,daherderNameipchains.DieseKettevon Regeln wird solangeabgearbeitet,bis entwedereineRegel zutrifft, oderdasEndederKetteerreichtist.1819Abgehendes PaketAbbruchAbbruchtrifft zuRegel 1AbbruchAbbruchNetzwerkSchnittstelleInputChainAnkommendes Pakettrifft zuJaNeintrifft zuJaNein Regel 2Regel 3AnnahmeOutputChainRegel 1trifft zuJaNeinAbbruchAbbruchtrifft zuRegel 3trifft zuRegel 2JaJaJaNeinNeinNeinBild 3.1: InputundOutputChains20 KAPITEL 3. GRUNDLAGENDER FIREWALLTECHNIK3.1 Die Voreinstellungfur PaketfilterAus demletztenBild kannder Eindruckentstehen,dadie Regeln grundsatzlichso auf-gebautsind,dasieeinzelnePaketeablehnen,ansonstenaberalleanderenannehmen.Dasist naturlich moglich, aberwedernotwendig,nochempfehlenswert.LinuxFirewalls bie-ten zwei verschiedeneStrategien an, nachdenendie Firewall arbeitet die sogenanntenPolicies: Grundsatzlichwird allesabgewiesen;nur explizit durchRegelnzugelassenePaketewerdenakzeptiert.DiesePolicy heitDENY. Grundsatzlichwird allesakzeptiert;nurexplizit durchRegelnverbotenePaketewer-denabgewiesen.DerNamedieserPolicy ist ACCEPT.Vor undNachteilebeiderStrategienliegenauf derHand.Die ersteVersionist sicherlichdie,die mehrSicherheitundKontrollebietet,jedochauchwesentlichmehrArbeit bei derEinrichtungerfordert.Wir mussenfur alle denkbarenArten von NetzverkehrRegelndefi-nieren,sonstwerdendieentsprechendenPaketeja nichtdurchgelassen.Die zweiteMethode(ACCEPT)ist bei derEinrichtungnaturlich wesentlicheinfacher, siebietetabervon sichauswesentlichmehrAngriffsflache.Um mit dieserMethodeeinehin-reichendsichereFirewall aufzubauen,musstenwir alle denkbarenAngriffstypenkennen,umsieentsprechendabzuweisen.Unddamitwareeswiedermindestenssoviel Arbeit,wiedasEinrichtenderDENYMethode.Zusammengefasstmualsogesagtwerden,da zumindestensfur Pakete,die ausdemunsicherenNetzins sicheregelangensollen dieStrategieDENY vorzuziehenist.Auf denbeidenfolgendenSeitensinddiebeidenunterschiedlichenStrategiennochmalalsFludiagrammedargestellt.3.1. DIE VOREINSTELLUNGFUR PAKETFILTER 21Wird angenommenACCEPTtrifft zuJaNeintrifft zuJaNein Regel 2Regel 3Regel 1trifft zuJaNeinIPPaketFirewall Policy DENYPaket abweisenWird angenommenACCEPTWird angenommenACCEPTBild 3.2: Die DENYPolicy22 KAPITEL 3. GRUNDLAGENDER FIREWALLTECHNIKtrifft zuJaNeintrifft zuJaNein Regel 2Regel 3Regel 1trifft zuJaNeinIPPaketFirewall Policy ACCEPTDENYDENYDENYPaket annehmenWird abgelehntWird abgelehntWird abgelehntBild 3.3: Die ACCEPTPolicy3.2. REJECTODERDENY 233.2 REJECT oder DENYDie LinuxFirewall MechanismenerlaubennebendenbeidenbereitsbesprochenenPoli-cies ACCEPTund DENY eine dritte, REJECT. Dabei handeltes sich im Wesentlichenum eineMutationvon DENY, alsoderAblehnungeinesPaketes.Ein Paketkannentwedereinfachverworfenwerden,dasentsprichthierdemDENY, odereswird zwarabgelehnt,je-docherhalt derAbsenderdesPaketeseineFehlermeldungmit Begrundung.DieseMethodewird alsREJECT(ablehnen)bezeichnet.Wird einPaket alsodurchein REJECTabgelehnt,soerhalt derAbsenderdesPaketeseineICMP Fehlermeldung,wird esdurchDENY abgelehnt,soverwirft die Firewall dasPaketeinfachundgibt keinerleiRuckmeldungandenSenderdesPaketesweiter.Es ist eigentlich zumindestensin einemSystemmit hohenSicherheitsanforderungenimmerbesser, Paketemit DENY einfachzu verwerfen,alseineFehlermeldungzuruckzu-geben.Dashatdrei Grunde: DurcheineFehlermeldungwird derDatenverkehrauf demNetzunnotig vergroert. Fehlermeldungenkonnenals Teil einerDenialofServiceAttackStrategie einge-setztwerden.Wenn etwa ein Angreifer, der einenRechnerim Internetblockierenwill, seineIPAdresseauf die deszu blokierendenRechnersfalschtund anschlie-endtausendevon bei IhnenverbotenenAnfragenmacht,dannwird Ihr RechnertausendevonFehlermeldungennichtandenRechnerdesAngreifers,sondernandenzublockierendenRechnerschicken. Fehlermeldungen und seiensie an sich noch so wenig aussagekraftig konneneinempotenziellenAngreiferdochzumindestensInformationengeben,dieerbessergarnicht hat.Etwaalleinedie ExistenzeinerFirewall oderahnliches.3.3 ZusammenfassungZusammenfassendkonnenwir also feststellen,daes zwei wesentlicheStrategien (Po-licies) gibt, die eine PaketfilterFirewall ausmachen.Entwederwir nehmenalle Pakete,auerexplizit verbotenen,an Policy ACCEPT, oderwir verweigerndie AnnahmeallerPaketeauerexplizit erlaubten Policy DENY.Zum Umgangmit einzelnenPaketenstehenunsdrei Methodenzur Verfugung:ACCEPT DasPaketwird angenommenDENY DasPaketwird stillschweigendverworfenREJECT DasPaket wird abgelehnt,abereswird eineICMPFehlermeldungandenAb-senderzuruckgeschickt.Grundsatzlich unterscheidenwir zwischender Input und OutputChain,alsoder Kettevon Regelnfur eingehendebzw. ausgehendePakete.Kapitel 4Filter n von eingehendenPaketenEineFirewall istgrundsatzlichin derLage,sowohl ankommende,alsauchabgehendePake-te zu filtern. In derRegel ist jedochdie FilterungderankommendenPaketedie wichtigereTechnik,wollen wir dochvermeiden,daAngriffe von auen,alsoausdemunsicherenNetz, auf unserzu schutzendesNetz stattfinden.In diesemKapitel werdendie Kriterienbesprochen,nachdenenwir eingehendePaketefiltern konnen.4.1 Filter n nach IPAdr essenAuf der Ebeneder Vermittlungsund Transportschichtist die IPAdressedie einzigeMoglichkeit, herauszufinden,werein Paket anunsgeschickthat.DieseInformationstecktim IPHeader, alsoderInformation,dieunsdieVermittlungsschichtubermittelt.Die Authentizitat dieserInformationist grundsatzlichfragwurdig.Es ist ein leichtes,dieIPAdressedesSenderseinesPaketeszufalschen,auchwenndadurcheinefunktionierendeKommunikationin derRegelunmoglichgemachtwird.Grundsatzlichkonnenwir sowohl Absender, alsauchEmpfangerIPAdressenalsKrite-rien fur eineFirewall benutzen.4.1.1 Filter n nachAbsenderAdressenDasKriterium fur die Entscheidung,ob wir ein Paket durchlassenodernicht ist hier al-so die AdressedesSenders,die unsja im IPHeaderzur Verfugungsteht.Hier kommenverschiedeneTechnikenzur Anwendung.Ablehnenvon gefalschtenoder ungultigen Adr essenEsist naturlich nicht soeinfachmoglich,gefalschteAdressenalssolchezuerkennen,aberesstehenunsjedochein paarMittel zur Verfugung,offensichtlichfalscheAdressenabzu-weisen.SechsHauptgruppenvon solchenAdressensolltenwir grundsatzlichablehnen:1. Die eigeneIPAdresse:Niemalskannein regular eingehendesPaket vom eigenenRechnerstammen.Esmusichalsozwangslaufigum eineFalschunghandeln.2. Die IPAdressen,die fur lokale NetzeohneInternetAnschlureserviertsind: FurjedeKlasse(A, B undC) existierenAdressen,die im Internetnicht geroutetwerdenkonnen.Aus demInternetkonnen(bzw. durfen)solchePaketeniemalsauf unserenRechnerkommen.Die sogenanntenprivatenAdressensind:KlasseA 10.0.0.0bis 10.255.255.255KlasseB 172.16.0.0bis 172.31.255.255KlasseC 192.168.0.0bis192.168.255.255244.2. FILTERNNACH PORTNUMMERN 25Pakete,die dieseAdressenhabenundausdemInternetkommen,konnenSiebeden-kenlosablehnen.3. MulticastAdressender KlasseD: Hierbeihandeltessichum reservierteAdressenfur sogenannteMulticastBroadcasts,wie sie etwa fur Audio oder Video Ubert-ragungan mehrereEmpfangerverwendetwerden.DieseAdressendurfen zwar alsEmpfangerAdressen,niemalsjedochalsAbsendervorkommen.EshandeltsichumdieAdressenim Bereichvon224.0.0.0bis239.255.255.255.4. Alle KlasseEAdressen:AdressendieserKlassewarenfur expeimentelleErweite-rungenvorgesehenund werdengrundsatzlich nicht offentlich vergeben.Sie liegenim Bereichvon 240.0.0.0bis 247.255.255.255. In derRegel werdendieseAdressenohnehinnur von USMilitarsund Geheimdienstenverwendet.Im Internetsolltensienieauftauchen.5. LoopbackAdressen:Die reservierteAdresse127.0.0.1ist eineAdresse,die immerdenlokalenRechnermeint.Ein Paket,dasausdemInternetkommtunddieseAdresealsAbsenderadresseeingtragenhatkannniemalseineechteAdressesein.6. BroadcastAdressen:BroadcastAdressensindAdressen,die in Netzenbenutztwer-den,ummehrereSystemegleichzeitiganzusprechen.SolcheAdressensindalsEmpfangerAdresselegal,alsAbsenderAdressejedochnie.BestimmteAdr essenherausfilternEsexistierenbestimmteAdressen,vondenenmanwei,davon ihnenoft Angriffe ausge-hen.Esist moglich,solcheAdressen,seienesHostoderganzeNetzAdresseneinfachzusperren.Auf deranderenSeiteist esauchmoglich, bestimmtenAdressendenZugriff aufbestimmteDiensteeinesNetzeszuzulassen.Sokannetwa die Filliale unsererFirma,vonderwir genaudie IPAdressewissen,auf unserenDatenbankServer zugreifen,wahrendsonstniemandaskonnensoll.4.1.2 Filter n nachEmpfangerAdressenDas Feld der EmpfangerAdresseist fur die Firewall danninteressant,wenn sie selbstauchRouterin ein Netz ist. In diesemFall kann bestimmtwerden,welcheRechnerimNetzeinPaketbekommendurfenundwelchenicht.Sokannetwa einbestimmterRechner(mit bestimmterIP-Adresse)im lokalenNetz ein Webserver sein,der naturlich fur ande-re Netzteilnehmererreichbarseinsoll. Ein Paket, dessenEmpfangerIPAdressenfelddieAdressediesesWebserversenthalt, mualsodurchgelassenwerden,alle anderenPaketekonntenwir sperren.4.2 Filter n nach PortnummernPortnummernsind InformationenausderTransportschicht,alsoentwederausdemUDPHeaderoderdemTCPHeader. Sie gebenan, welchesProgrammauf der Anwendungs-schichtein eingehendesPaket erhalt (EmpfangerPortnummer) odervon welcherAnwen-dungeinPaketgeschicktwurde(AbsenderPortnummer).BeideFallesindwichtigeInfor-mationenfur eineFirewall.4.2.1 Filter n nachder AbsenderPortnummerHier mussenwir unterscheiden,ob essich um ein Paket handelt,daseineAnfragenacheinemlokalenServicebeantragt(alsoein Client von auerhalb,dereinenServicevon in-nerhalbnutzenwill). In diesemFall wird die PortnummereineNummerzwischen1024und65535seinmussen.26 KAPITEL 4. FILTERNVON EINGEHENDENPAKETENIm umgekehrtenFall, alsowenneinClientvon innerhalbeinenServicevonauerhalbnut-zenwill, dannwird eineingehendesPaketdieAbsenderPortnummerdesjeweilsgenutztenDiensteshaben1.4.2.2 Filter n nachder EmpfangerPortnummerDiesesFeldist fur unssehrinteressant,weil hier zumindestensbei eingehendenPaketen die PortnummerdesDienstessteht,denein Uservon auerhalbnutzenwill. Dasheit,hier ist derOrt, wo wir von vornehereinnur die Paketedurchlassen,die PortnummernvonDienstenenthalten,diewir auchanbietenwollen.Auch hier gibt esjedochdenzweitenFall, namlichdie Antwort einesfremdenServersaufeineNachfrageeineslokalenClients.In demFall liegendie EmpfangerPortnummernimunprivilegiertenBereichzwischen1024und65535.4.3 Filter n nach TCPStatusFlagsAuch dieseInformationstammtausderTransportschicht,stehtjedoch im GegensatzzuPortnummern nur beiTCP, nicht bei UDP zur Verfugung.Hier gehtesim Speziellenumdie FragedesHandshakesbeimVerbindungsaufbau.Der zugrundeliegendeMechanismuswurdeabSeite15 genaudargestellt.DieseInformation ist fur eine Firewall von dahersehrwichtig, damit ihrer Hilfe un-terschiedenwerdenkann, ob ein Paket eine Anfrage von auenoder eine Antwort aufeine Anfrage von innen enthalt. Pakete,die Antworten fremderServer enthaltenhabengrundsatzlichdasACKFlaggesetzt.FirewallRegelnkonnendaherz.B.entscheiden,dain ein interneszuschutzendesNetznurPaketemit diesemFlaghereingelassenwerden.4.4 Angriffsf ormen von auerhalbUm eineFilterungeingehenderPaketeuberhauptsinnvoll zu nutzen,ist esnotwendig,diegangigenFormenvon Angriffen von auerhalbzu kennen.Im Folgendensollenkurz diehaufigstenAngriffsformenbeschriebenwerden,die keinenormalenZugriffe auf Dienstesind.4.4.1 PortscansEin Portscanist ein Abtastversuch ein Versuch,zu einembestimmtenPort eine Ver-bindungaufzubauenoderzumindestenseineReaktionzu erhalten,ausder Ruckschlussemoglich sind,ob ein bestimmterDienstangebotenwird odernicht. Der Begriff Scanbe-zeichnetdabeieineSerievon Abtastversuchenauf verschiedenePorts.Dazuwerdensoge-nanntePortscannerbenutzt,dieeinfachverschiedene odergaralle PortseinesRechnersansprechenundauf Antwort warten.Obwohl der eigentlicheVersucheinesPortscansselbstnoch kein Einbruchsversuchist,ist erdochmeistensderersteSchritteinesAngriffs.Ein potentiellerAngreiferkannmittelsPortscanherausfinden,aufwelchemPorteinesbestimmtenRechnersAnwendungenlaufen,dieAntwortenverschicken.Mit dieserGrundinformationkanndanneineAngriffsstrategiefestgelegt werden.ManunterscheidetzwischenkomplettenPortscans, dieallePortszwischen0 und65534ab-fragenundgezieltenPortscans, dienurbestimmte alspotentiellgefahrlicheinzuschatzen-de Portsuberprufen.KompletteScanssindheuteeherselten,weil sieviel Zeit benotigenunddaherauchleichtbemerktwerden.AktuelleUtilities sindheutein derLage,bestimmtePortsabzufragen,die sich fur Angriffe von aueneignen.DaskostetwenigerZeit und istdaherauchwenigerleicht zuerkennen.1Siehe/etc/services4.4. ANGRIFFSFORMENVON AUSSERHALB 27TypischePorts,diegernegescanntwerdensindin derTabelleim Anhang(Seite69) aufge-listet.Mit einerinstalliertenFirewall werdensolchePortscannsnaturlich bemerkt.Allerdingsunddazuhabenwir ja eineFirewall bedeutetderScanansichnochkeinerealeGefahr.Jemandversuchtetwas uberunserSystemherauszufinden,wird jedochvon der Firewallabgewiesen.. .4.4.2 DenialofServiceAttacksEinewesentlichgefahrlichereArt desAngriffs ist diesogenannteDenialof ServiceAttack,oft alsDoSabgekurzt.Hierbeiwird versucht,einenComputerderartmit Datenpaketenzuuberfluten,daerentwederkeineanderenPaketemehrverarbeitenkann,oderim schlimm-stenFall komplettabsturzt. Eine Abart dieserAngriffsform ist die DistributedDenial ofServiceAttack (DDoS),beidernicht nurein,sondernvieleComputergleichzeitigunserenRechnermit Paketenuberschwemmen.Es gibt keinenvollkommenenSchutzgegensolcheAngriffsformen,daherist eswichtig,zumindestensdie wichtigstenFormendiesesAngriffs zu kennen.Im Folgendensolleneinpaardargestelltwerden:TCPSYNFloodingDieseAngriffsformbestehteinfachdarin,dendreiteiligenHandshakeeinerTCPVerbindung(sieheSeite15) zu unterbrechen.Wenn ein Client einemServer eine Anfrage stellt, soschickter demServer ein Paket mit gesetztemSYNFlag.Der Server schicktalsAntwortein Paket mit einemgesetztenSYN undACKFlag.Damit ist die Verbindunghalboffen.WennderClient jetztkeineAntwort mit gesetztemACKFlagschickt,dannhalt derServerdieseVerbindungin derRegel fur etwa 5 Minutenoffen.WennderClient jetzt erneut(mit andererSequenznummer)eineSYNNachfrageschickt,dannmuderServereinenneuenKanaloffnen.SogehtdasSpielchenweiter, bisderServerkeineKanalemehrzur Verfugunghat.Im schlimmstenFall wird derServerdannganzlichabsturzen,im mindestenFall kannerkeineweiterenDiensteanandereanbieten.Die SYNFlagAnfragepaketewerdennormalerweiseeinegefalschteSenderIPAdressehaben,derSendererwartetja keineAntwort, erwill ja nur storen.Linux bieteteinespeziellgegendieseAngriffsform gerichteteKerneleigenschaft,die so-genanntenSYNCookies.Damit kannsich ein LinuxKernelerfolgreichgegenAngriffedieserArt wehren.PING-FloodingDasProgrammping wird benutzt,um festzustellen,ob ein betimmterRechneruberdasNetz erreichbarist. DiesesProgrammschickteineICMPEchoanforderungan einenbe-stimmtenRechnerundwartetdannaufebendiesesEcho.Die Tatsache,daessichhierumICMP (sieheSeite12) handelt,zeigtschon,daping hier nicht uberdie Netzwerkschicht(Vermittlungsschicht)hinausgeht.EsexistierenalsokeinerleiPorts.Wennein RechnereinenanderenRechnermit pingAnfragenuberhauft, sokannesdazukommen,dadieserandereRechnerkeineBandbreitemehr fur andereNetzwerkdiensteubrighat,er ist alsoauchfaktischlahmgelegt.AltereUnixVersionen(nichtLinux) warenauchanfallig gegendassogenannteTodesping,eineEchoanforderung,die zu groeDatenpaketeverschickt.DiesealtenRechnerkonntendanntatsachlichzumAbsturzgebrachtwerden.28 KAPITEL 4. FILTERNVON EINGEHENDENPAKETENUDP-FloodingDasUDPProtokoll eignetsichhervorragendfur DenialofServiceAngriffe. Es ist ver-bindungslos,d.h., es existiert keine Flukontrolle, kein Handshake, keine Sequenznum-mern.. .Es ist alsosehreinfach,einenRechnermit UDPAnfragenderartzu uberhaufen,dakeineBandbreitemehrfur andereNetzwerkdiensteubrigbleibt.UDPist traditionellabersowiesofur DiensteinnerhalbdeslokalenNetzesbestimmt,Dien-ste im Internetbenutzenfast immer TCP als Transportprotokoll. Viele Firewalls lassendahergrundsatzlich keine oder nur ein paarausgewahlte UDPDienstanfragenausdemunsicherenNetzzu.ICMPRedir ectAngriffDer NachrichtenTyp 5 des InternetControl MessageProtocol ist dazugedacht,einenComputeranzuweisen,seineRoutingTableszugunstenandererRoutenumzustellen.DieseFunktionalitatist abernurdanngewahrleistet,wennaufdemRechnerentwederdergatedoderderrouted lauft.Im Fall einesAngriffs, kannder Angreifer Ihren Rechnermiz dieserMethodeanweisen,alle ausgehendenPaketeuberihn zu routen.DaskameeinerKatastrophegleich,kannerdochsojedesein- undausgehendePaketmanipulieren.Kapitel 5Filter n von ausgehendenPaketenDasFiltern ausgehenderPaketeist soferndenUserndeslokalenNetzesVertrauenent-gegengebrachtwird deutlichunkritischer, als dasFiltern eingehenderPakete.Auf deranderenSeiteist esnaturlich in mancherleiHinsicht trotzdemratsam,auchdiesePaketeeinerPrufungzu unterziehen,bevor mansie in die weiteWelt entlasst.Auch hierzufolgteinekurzeDarstellungderjeweiligenKriterien.5.1 Filter n nach IPAdr essenAuch hier unterscheidenwir wiederzwischenAbsender und Empfangeradresse.BeideFalle bietenein paarnennenswerteKriterien fur einePaketfilterfirewall:5.1.1 Filter n nachAbsenderAdresseDasKriterium fur dieSenderadressefur abgehendePaketeist simpel.Esmusichumeineim lokalenNetzgultigeAdressehandeln.Also entwederumeinenbestimmtenAdresspool,oderumeineklareListevonAdressen,diewiederumentwederfestvergebensind,odervoneinemDHCPSerververwaltetwerden.Bei einerVergabevon AdressenuberDHCP kommt esbeim Aufbau der VerbindungzueinerspeziellenSituation,dieabernurdanneineRollespielt,wennsichderDHCPServerauerhalbdeszuschutzendenNetzesbefindet.Und dasist grundsatzlichkeineguteIdee.5.1.2 Filter n nachEmpfangerAdresseBei derFragederFilterungnachderEmpfangerAdresseabgehenderPakete,gibt eszweiwesentlicheBereiche.Wir unterscheidenhier grundsatzlich,ob dasPaket aneinenServerim Internetgerichtetist, oderob esan einenClient im Internetgeht,dereinenServer imLAN angesprochenhatte.1. PaketeaneinenServer im Internet:Hier ist esmoglich,bestimmteIPAdressenoderDNSNamenkomplettzusperren,weil esunerwunschtist, daausdemLAN herausdieseDiensteangenommenwer-den.Eskannauchz.B. ein bestimmtesProtokoll (z.B. POP3oderIMAP) an einenbestimmtenRechnergebundenwerden,alle anderenAdressenwerdennicht durch-gelassen.. .2. PaketeaneinenClient im Internet:UnserNetzhatvielleichteinpaaroffentlicheServer, dievonjedemClientausbenutztwerdendurfen(Webserver, FTPServer.. . ), eshataberandererseitsauchDiensteimAngebot,die nur fur bestimmteRechnerim Netz zur Verfugungstehensollen.Soetwa die Filiale in eineranderenStadt,derenIPAdressewir kennen.In so einem2930 KAPITEL 5. FILTERNVON AUSGEHENDENPAKETENFall ist esdurchaussinnvoll, nicht nur die eingehendenPakete,sondernebenauchdieausgehendenPaketevon derFirewall unterdruckenzu lassen.5.2 Filter n nach PortnummernAuchhierunterscheidenwir wiederzwischenAbsender undEmpfangerport.Fur ersterenist zubemerken,daeinAbsenderporteinesClientsausdmlokalenNetzgrundsatzlichei-nePortnummerausdemunprivilegiertenBereichhabensollte,ServerprozessedeslokalenNetzeskonnenwiederumnur die zugelassenenPortsbenutzen.Hier habenwir wiederumeinedoppelteMoglichkeit, zu verhindern,daungewollte Diensteins globaleNetzgelan-gen.Die EmpfangerportshabeneineahnlicheBeschrankung.Wennein ServerprozessausdemlokalenNetzein Paket aneinenClient im Internetschickt,sodarf derEmpfangerportnurein unprivilegiertersein.Umgekehrt vermeidenwir dasSendenvon Paketen,mit privile-giertenPortnummernvonunserenClientsins Internet.5.3 Filter n nach TCPStatusFlagsWie bei den ankommendenPaketen,konnenwir auchbei den abgehendenPaketendieStatusflagsnutzen,um zu entscheiden,ob ein Paket von einemClient oder von einemServerstammt. Wennein lokalerClient einenDienstim Internetanspricht,dannist im erstenPaketnurseinSYNFlaggesetzt,nicht jedochdasACKFlag.Alle weiterenPaketehabennurnochdasACKFlaggesetzt,nicht jedochdasSYNFlag. WenneinlokalerServereinenDienstim Internetanbietet,dannsindim erstenPaket,daser verschicktbeideFlags(SYN und ACK) gesetzt,alle weiterenPaketehabennurdasACKFlaggesetzt.Kapitel 6Gestaltungeiner Fir ewall mitLinuxNachdemnunalle wichtigentheoretischenVoraussetzungenerfullt sind,ist esanderZeit,diekonkreteUmsetzungeinerFirewall unterLinux anzusprechen.Linux hat,im Gegensatzzu denmeistenanderenBetriebssystemen,die Funktionalitat der Firewall bereitsim Be-triebssystemkern(Kernel)festeingebaut.Dasmachtdie Firewall sowohl stabiler, alsauchwesentlichschneller, alswennsieim sogenanntenUserspacerealisiertwerdenmusste.6.1 Die drei StandardKettenWir habenbereitsgesehen,daeineFirewall unterLinux ausvieleneinzelnenRegelnbe-steht,die zu einerKette(chain) zusammengefasstwerden.StandardmaigexistierendreiKetten,eskonnenaberbeliebigvieleweitereKettenerstelltwerden z.B.spezielleRegelnfur einenModemanschluoderahnliches.Die dreiStandardKettensind input,outputundforward.WenneinPaketvonauenaneinerbeliebigenNetzwerkSchnittstelleankommt,dannwirdseinHeadermit jederRegel der inputChainverglichen,solangebis entwedereineRegelzutrifft, oder dasEndeder Regelketteerreichtist. JedeRegel, die zutreffen sollte, kannals Folge ein ACCEPT, REJECToderDENYdefiniert haben.Erst, wenndasEndederKetteerreichtist, wird die voreingestelltePolicy derChainaktiv, die wiederumeinenderdrei WerteACCEPT, REJECToderDENYdarstellt.Die erstegefundenepassendeRegelkommtzumZug.Genausoverhalt es sich mit den Paketen,die zu einer beliebigenNetzwerkschnittstellegeschicktwerden,um denComputerzu verlassen.In diesemFall tritt statt der inputChain die outputChainin Kraft.Wennein Paket nicht fur denRechnerbestimmtist, auf demdie Firewall lauft, sondernanandereRechnerweitergeleitet(geroutet)werdensoll, danntritt die dritteRegelkettezu,die forwardChain.DieseRegelkettekannnebendennormalenRegelnnocheineweitereFahigkeitanbieten,dassogenannteMasquerading.HierbeihandeltessichumdieFahigkeitdesKernels,zuroutendePaketezumaskieren,sodavonauenderEindruckerwecktwird,siekamenausschlielichvon demFirewallRechner. DashatzweiVorteile: Ein internesNetzwerkkannmit reserviertenIPAdressenarbeiten,trotzdemkannjederRechnerdesinternenNetzesuberdie Firewall nachauenins Internetgelan-gen. Vonauenist dieStrukturdesinternenNetzesnichtsichtbar, weil esnachauenhinnur die IPAdresseder Firewall gibt. Ein Angriff auf einenRechnerinnerhalbdesNetzesist vondaherschonunmoglich,dajederRechnerinneneineAdressehat,dieim Internetgarnicht geroutetwerdendarf.3132 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUXZusammengefasstkonntemaneineFirewall mit all ihrenRegelkettenalsofolgendermaendarstellen:ChecksummeSanityCheckDemasqueradeRouting OutputChainInputChainForwardChainDeny/RejectDeny/RejectDeny/RejectAcceptAcceptAcceptlocalexternalBild 6.1: ArchitekturderIP-Chainsim KernelDie Regelnder einzelnenKettenwerdenin Tabellenim Kernelgespeichert,fur jedeein-zelneKetteeineeigeneTabelle.DieseRegelnstehenin derReihenfolgeim Kernel,in dersieeingegebenwurden.In manchenFallenist esnotwendig,die Reihenfolgezu beachten,weil einefalscheReihenfolgedenSinnderRegelnumwerfenkonnte.Zur Erinnerung,dieerstepassendeRegel zahlt.Esist auchmoglich,RegelnamAnfangeinerKetteneueinzufugen,in derPraxisist jedochderAufbauvonFirewallRegelnnicht,wasmanbei jedemStartvonHandubernimmt.Wirwerdenim Gegenteilnaturlich Scripteerstellen,die die Regelndefinierenunddie bei je-demStartausgefuhrtwerden.JedenotwendigeAnderungvonRegelnsollteauchimmerindiesenScriptenstattfinden,dennVon Hand eingegebeneFir ewallRegelnsind nachdemnachstenNeustart verschwun-den!6.2 DasHandwerkszeug:ipchainsDasProgramm,mit demwir FirewallRegelnerstellen,bearbeitenoderloschenheitip-chains und ist sozusagenein Werkzeugzur ManipulationderRegeltabellenim Kernel.DiesesProgrammsollte im Verzeichnis/sbin liegenundnur vom Systemverwalterauf-gerufenwerden.Als typischesUnixProgrammwird esausschlielichuberdie Komman-dozeilegesteuert,also uber einenBerg von verschiedenenKommandozeilenparametern.Dasist von daherwichtig, dawir ja Scripteschreibenwollen, die die einzelnenRegelnerstellen.Nur mit einemKommandozeilenorientiertenProgrammkanndasgelingen.ipchains ist einProgramm,dasfur jedeFirewallRegeleinmalaufgerufenwerdenmu.Die wichtigenParameterwerdenjetzt kurzdargestellt.EinevollstandigeBeschreibungderParameterfindenSieaufderentsprechendenManPageipchains(8) undim IPCHAINS-HOWTO.6.3. FORMAT DERANGABEN 33ipchains-A | -I [Chain][-i Interface][-p Protokoll][[!] -y][-s Adresse [Port[:Port]]][-d Adresse [Port[:Port]]]-j Policy[-l]-A [ Chain] Hangt eine Regel ans Ende der angegebenenKette(Chain) an. Wenn keine Chain angegebenwird, so giltdieRegel fur alle Chains.-I [ Chain] Fugt eineRegel vor denAnfangder angegebenenKette(Chain)ein. WennkeineChainangegebenwird, so giltdieRegel fur alle Chains.-i Interface Netzwerkinterface,fur dasdie Regel gelten soll. Wirdkein Interfaceangegeben,so gilt die Regel fur alle In-terfaces.-p Protokoll Protokollnamenoder nummer, fur das die Regel gilt.Gultige Werte sind hier tcp, udp, icmp und all .Danebensind alle Protokollnamenund nummernaus/etc/protocols erlaubt.-y Das SYNFlag einer TCPNachrichtmu gesetzt,dasACKFlagdarf nicht gesetztsein.DasPaket ist alsodasersteeinesVerbindungsaufbauesundkommtvomClient.! -y DasACKFlageinerTCPNachrichtmu gesetztsein.Dasheit,dasPaket ist entwederderzweiteTeil desVer-bindungsaufbauesoder, esist ein Teil einerbestehendenVerbindung.Ist weder-y noch! -y gesetzt,werdendieTCPFlagsnicht uberpruft.-s Adresse [ Port] AbsenderAdressedesPaketes.Wenn keine Absender-adresseangegebenwird, so sind alle Adressenange-sprochen.Wennzusatzlichein Portoderein Portbereich(Port:Port)angegebenist, so gilt die Regel nur fur die-sePorts.Sind keinePortsangegeben,so sind alle Portsgemeint.-d Adresse [ Port] EmpfangerAdressedes Paketes. Ports wie bei derAbsenderAdresse.-j Policy Policy dieser Regel. Gultige Policies sind ACCEPT,REJECTundDENY. In derforward Chainist auchdiePolicy MASQfur Masqueradingzulassig.-l Logbucheintrag.Jedesmal,wenn diese Regel zutrifft,wird einesyslog MeldungderHerkunftkern undderPrioritat info erzeugt.6.3 Format der Angaben6.3.1 IPAdr essenEineFirewallRegel kannsowohl eineSender, alsaucheineEmpfangeradressebeinhal-ten. In diesemFall gilt die Regel dannebennur fur dieseAdresse.Statt der AdressenkonnenauchdieRechnernamenangegebenwerden,dashatabereinpaargewichtigeNach-teile.Zur NamensauflosungmueinfunktionierendesDNSSystemvorhandensein.Diese34 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUXVoraussetzungkonnte zumindestensam AnfangeinerRegelkette nochnicht gegebensein,wennDNS selbsteinerBeschrankungunterliegt. Es ist dahergrundsatzlich ratsam,stattNamenebenIPAdressenzuverwenden.ZumAnderenkonnenDNSNamenleichtergefalschtwerden,alsIPAdressen.IPAdressenkonnendazunochmit einerMaske versehenwerden,die die signifikanntenBits derAdresseangibt.DieseMaske wird alsBitmaske realisiertundeinfachmit einemSlash(/ ) hintenandieAdresseangehangt.Die Bedeutungist einfach,die Adressangabe192.168.100.123/24bedeutet,dadieersten24Bit derAdressangabemit dergefundenenAdresseubereinstim-menmussen,damit die Regel greift. In diesemBeispielsind dasalsoalle Adressen,dievorne192.168.100 stehenhaben.EineMaske /32 bedeutetalso,dadieAdresseexaktubereinstimmenmu,eineMaske /0 bedeutet,dakeinBit ubereinstimmenmu,alsoalleAdressengemeintsind.Dafur ist auchdieAbkurzungany/0 zulassig.6.3.2 PortsPortskonnensowohl alsPortnummer, alsauchalssymbolischeNamenangegebenwerden,wie sie in /etc/services eingetragensind. Allerdings hat der Eintragdessymboli-schenNamensdenNachteil,dadieseNamennicht immergleichsind,siesindnicht festvorgegeben.Bei einemDistributionswechselkonnteesvorkommen,daeineFirewallregelnichtmehrfunktioniert,wennebendieNamenderPortssichveranderthaben.Andererseitsist naturlich einNameaussagekraftiger, alseineNummer.6.4 Praktischer Aufbau einer Fir ewallEine Firewall wird grundsatzlichaufgebaut,indemjedeeinzelneRegel durcheinenAuf-ruf von ipchains angegebenwird. Das ist eineAufgabe,die naturlich nicht jedesmalvon Handausgefuhrt wird, sondernimmer in Form einesScriptserledigtwerdensollte.Ein solchesScriptkannnachjedemNeustartneugeladenwerdenundeswird nichtsdabeivergessen.Es ist in fastallen Fallen unsinnig,einzelneRegeln von Handim Nachhineineinzufugen.Ein solchesScript muselbsterstelltwerden,auchwennDistributorenwieetwa S.u.S.EschonvorgefertigteScriptsenthalten.Wir werdenunshier ein solchesexem-plarischesScripterstellen.6.4.1 GrundeinstellungenZum besserenVerstandnisdereinzelnenRegeln ist esublich,einzelne,immerwiederkeh-rendeBegriffe, Adresseno.a.alsKonstantenvorzudefinieren.Fangenwir mit einemeinfa-chenBeispielan,in demdie Firewall nur sichselbstschutzt (DasvollstandigeScript liegtim AnhangabSeite72 nochmalzur Einsicht):EXTERNAL_INTERFACE=eth0 # Das fremde NetzLOOPBACK_INTERFACE=lo # Local LoopbackIPADDR=192.168.100.1 # Eigene AdresseANYWHERE=any/0 # Jede IP-AdresseMY_ISP=123.45.67.89/16 # Der Bereich meines ProvidersLOOPBACK=127.0.0.0/8 # Loopback-AdressbereichCLASS_A=10.0.0.0/8 # Reservierter Bereich Klasse ACLASS_B=172.16.0.0/12 # Reservierter Bereich Klasse BCLASS_C=192.168.0.0/16 # Reservierter Bereich Klasse CCLASS_D=224.0.0.0/4 # Komplette Klasse D6.4. PRAKTISCHERAUFBAU EINERFIREWALL 35CLASS_E=240.0.0.0/5 # Komplette Klasse EBROADCAST_SRC=0.0.0.0 # Broadcast AbsenderBROADCAST_DEST=255.255.255.255 # Broadcast EmpfangerPRIVPORTS=0:1023 # Privilegierte PortnummernUNPRIVPORTS=1024:65535 # Unprivilegierte PortnummernDer ersteSchritt,zum Aufbau einerneuenRegelsammlungist immer dasLoscheneven-tuell schonbestehenderRegeln. DasProgrammipchains kannseineChainsmit demParameter-F (Flush) loschen.WennkeineChainangegebenwird, dannloschenwir alleeingebautenChains,alsoinput, output undforward .# Alle bestehenden Regeln l oschenipchains -FAlle Kettensind jetzt leer. Allerdings habenwir nochnicht die Grund-Policiesgeloschtbzw. verandert.SiebleibenauchnachdemLoschenvorhanden.Also stellenwir jetztdiesePoliciesein, fur jedeKetteextra.Dazustellt ipchainsdenParameter-P (nichtverwechselnmit -p) zur Verfugung:# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECTAb diesemPunkt ist zumindestensfur unserenRechner jeder Netzwerkverkehr ge-sperrt.Die Grundeinstellungenlehnenallesab,einzelneRegelnhabenwir nochnicht.Nungebenwir demLoopbackInterfacealle Rechte.Von diesemInterfacedroht unskeinerleiGefahr, abereinzelnelokaleDienstewie Drucker oderX11 konnennicht ohneLoopbackfunktionieren:# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT6.4.2 Ein paar Techniken zur Abwehr von gefalschtenPaketenNun habenwir eine Grundeinstellung,mit der sich bereitsarbeitenlasst.Allerdings istbisherauerdemlokalenLoopbacknochnichtserlaubt.Bevor wir jetzt weitereRegelnerstellenist essinnvoll, nochein paarSicherheitsmechanismengegenSYNFloodingundgefalschteIPPaketeeinzubauen.Der LinuxKernelenthalt bereitseinigedieserMecha-nismen,die wir nur noch aktivierenmussen.Dazu stehenein paarsehrLinuxtypischeWegezur Verfugung.DasVerzeichnis/proc enthaltDateien,dieeigentlichkeineDateiensind,sondernSchnitt-stellenzumKernel.EinigedieserDateienermoglichenes,bestimmteFahigkeitendesKer-nels ein oder auszuschalten.Dasgeschieht,indemin dieseDateieneine 1 oder eine0hineingeschriebenwird. Fur uns sind dabeiinsbesonderedie folgendenDateieninteres-sant: /proc/sys/net/ipv4/tcp syncookiesschaltetdenSchutzmechanismusgegenSYN-Floodingein/aus.36 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX /proc/sys/net/ipv4/conf/*/rp filterDasVerzeichnis/proc/sys/net/ipv4/conf enthalt fur jedesIPInterfaceeinUnterverzeichnis,in demjeweilseineDateirp filter liegt.DieseDateienermogli-chenes,diesogenannteSourceAddressVerificationeinzuschalten.In all dieseDateienschreibenwir jetzt eine1 hinein,um die jeweiligenMechanismenzuaktivieren.Auch dasgeschiehtinnerhalbunseresScripts:# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdoecho 1 > $idone6.4.3 Ausfiltern offensichtlich falscher Adr essenEsgibteinpaarAdressen,diewir grundsatzlichablehnenkonnen,weil sienielegalausdemexternenNetz(Internet)kommenkonnen.Dazuzahlt zuersteinmaldieeigeneIPAdresse,danachalle AdressenausreserviertenAdressbereichen.Also verbietenwir zunachstjedesPaket,dashereinkommtundvorgibt vonunserereigenenAdressezustammen:# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammenipchains -A input -i $EXTERNAL_INTERFACE-s $IPADDR -j DENY -lDie beidenverwendetenBegriffe $EXTERNALINTERFACEund$IPADDRhattenwir jaobenbeiderKonstantendefinitionfestgelegt. Dasangehangte-l bedeutet,da,fallsdieseRegel zutrifft eineMeldungandensyslogd gehtundderVorfall protokolliert wird.DernachsteSchrittist dasVerbotallereinundausgehenderPaketemit reserviertenAdres-sen sowohl Sender als auchEmpfangeradressen.Wir hattenja bei der Definition derKonstantenextradieseBereichedefiniert,jetzt brauchenwir sie:# Reservierte A-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENY# Reservierte B-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENY# Reservierte C-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENY6.4. PRAKTISCHERAUFBAU EINERFIREWALL 37Noch eine Adressform,die denkbarungultig ist, ist die Verwendungeiner LoopbackAdressealsAbsenderAdressevom externenInterface.WedereinnochausgehendePa-ketedurfendasvorweisen:# Pakete mit Loopback als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYAls nachstesfiltern wir illegaleBroadcastAdressenaus,dasheitBroadcastAdressen,diedieBroadcastAbsenderAdressealsEmpfangerAdressehabenoderumgekehrt:# Pakete mit illegalen Broadcast Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $BROADCAST_DEST-j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $BROADCAST_SRC-j DENYJetztfolgendieAbweisungderKlasse-DAdressenim AbsenderFeld.KlasseDAdressensindsogenannteMulticastAdressen,diegrundsatzlichnur im EmpfangerFeldauftauchendurfen.Wir verbietendieseAdressenim Absenderfeldsowohl fur ein,alsauchfur ausge-hendePakete:# Pakete mit Klasse-D Adresse als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_D -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_D -j REJECTAls nachstesverbietenwir alle Arten von KlasseEAdressen,weil dieseAdressenreser-viert unddahernie legal seinkonnen.Hier genugt es,die eingehendenPaketezu untersu-chen:# Klasse-E Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_E -j DENYNebendenreserviertenAdressenderverschiedenenKlassen,hatdiezentraleVergabestellefur Internetadressen(IANA) nocheinige weitereA und BKlasseAdressenreserviert.DieseAdressendurfen nicht im offentlichenInternetauftauchen,also schlieenwir sieaus.Eshandeltsichumdie Netzadressen 02.*.*.* 5.*.*.* 7.*.*.* 23.*.*.* 27.*.*.* 31.*.*.* 37.*.*.* 39.*.*.* 4142.*.*.* 5860.*.*.*38 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX 6569.*.*.* 8095.*.*.* 96126.*.*.* 217219.*.*.* 220223.*.*.*Dasist viel Arbeit, weil leiderbei einigenFallendie Maskenandere,legaleAdressenmit-nehmenwurden.Esbleibt unsalsonichtsanderesubrig,alsdieseAdresseneinzelnanzu-geben:# Von der IANA reservierte Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s 1.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 2.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 5.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 7.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 23.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 27.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 31.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 37.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 39.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 41.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 42.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 58.0.0.0/7 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 60.0.0.0/8 -j DENY# 65 entspricht 01000001 - also wurde die Maske /3 leider die 64# mit ansprechen. Wir mussen daher 65-79 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 65.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 66.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 67.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 68.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 69.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 70.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 71.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 72.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 73.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 74.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 75.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 76.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 77.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 78.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 79.0.0.0/8 -j DENY# 80-95 l asst sich mit der Maske /4 ansprechenipchains -A input -i $EXTERNAL_INTERFACE-s 80.0.0.0/4 -j DENY# 96-111 l asst sich mit der Maske /4 ansprechenipchains -A input -i $EXTERNAL_INTERFACE-s 96.0.0.0/4 -j DENY# 126 entspricht 01111110 - die Maske /3 wurde 127 beinhalten# daher mussen wir 112 - 126 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 112.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 113.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 114.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 115.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 116.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 117.0.0.0/8 -j DENY6.4. PRAKTISCHERAUFBAU EINERFIREWALL 39ipchains -A input -i $EXTERNAL_INTERFACE-s 118.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 119.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 120.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 121.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 122.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 123.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 124.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 125.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 126.0.0.0/8 -j DENY# 217-219 einzelnipchains -A input -i $EXTERNAL_INTERFACE-s 217.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 218.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 219.0.0.0/8 -j DENY# 220-223 -> /6ipchains -A input -i $EXTERNAL_INTERFACE-s 220.0.0.0/6 -j DENYDamit hattenwir die offensichtlichungultigenAdressenjetzt ausgefiltert.Alleine dasVo-lumendieserRegelnzeigtnochmaldeutlich,dasienicht jedesmalbeimStartneueinge-gebenwerdensollten.Naturlich kannsoviel Informationnur in Form von Scriptenverar-beitetwerden.Jetztkonnenwir anfangen,bestimmteDingezuzulassen wir erinnernuns,die voreingestelltePolicy ist ja DENY, allesist verboten,wasnicht grundsatzlicherlaubtist.6.4.4 ICMPNachrichten filter nICMP, dasInternetControlMessageProtocol,wird benutzt,um Fehler bzw. Kontrollme-chanismenzu tansportieren.Esarbeitetauf der IPSchichtundsomiteigentlichnicht mitPortnummern.TrotzdemunterscheidetICMP verschiedeneNachrichtentypen,die ausderSichtderFirewall wie Portnummernverwendetwerden.EineListe derwichtigstenNach-richtentypensamtihrenPortnummernfindenSieim Anhangauf Seite71.Vier ICMPTypenmussengrundsatzlichdieFirewall passieren:source-quench, parameter-problem ,eingehendedestination-unreachable sowie ausgehendedestination-unreachable NachrichtenvomSubtypfragmentation-needed .Vier weitereTypensind optional,dazugehorendie beidenfur ping notwendigenTypenecho-request undecho-reply,sowie alleanderenSortenvon abgehenderdestination-unreachable Meldungenund time-exceeded . Alle anderenTy-penignorierenwir, siewerdendannvondervoreingestelltenPolicy abgewiesen.. .Wir akzeptierensource-quench (Typ4)Pakete.SiewerdenzurSynchronisationbenotigt,wenneinRouterschneller, alsein andererist.# ICMP Typ 4 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE4 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 4 -d $ANYWHERE-j ACCEPTDie Darstellungist mittelsBackslashin zweiZeilengebrochen,dasdientnurderbesserenLesbarkeit, nichtderFunktionalitat.Wir erlaubenalsoeingehendePaketevomTyp ICMP4 vonuberallhermit unsererAdressealsEmpfanger, sowieausgehendePaketediesesTyps,von unsuberallhin.Genausoverfahrenwir mit derStatusmeldungparameter-problem (ICMPTyp 12).Wir erlaubendieseTypen von uberall her zu unsererAdresseund von unsererAdresseuberallhin:40 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX# ICMP Typ 12 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE12 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 12 -d $ANYWHERE-j ACCEPTBei der Fehlermeldungdestination-unreachable (ICMPTyp 3) liegt die Sacheetwasanders.SolcheFehlermeldungenentstehennamlichwahrendeinesPortscans,wennein Angreifer versuchtherauszufinden,welchePortsgeoffnet sind. Die einfachsteFormwarejetzt,diesenTyp ganzzusperren,dasgehtaberleidernicht,denneinUntertypdieserMeldung (fragmentation-needed ) wird zwingendfur dasAushandelnder Paket-groeim Netzbenotigt. Aus diesemGrundkonnenwir alle Typ3Nachrichtennur anden(oderdie)RechnerunseresProviderszulassen,wahrendwir denSubtypfragmentation-neededanalle erlauben:# ICMP-Typ 3 f ur Providerrechner erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE3 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 3 -d $MY_ISP -j ACCEPT# ICMP-Typ 3 Subtyp fragmentation-needed f ur alle freigebenipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR fragmentation-needed -d $ANYWHERE-j ACCEPTDie letztezwingendeICMPNachrichtist die Statusmeldungtime-exceeded (ICMPTyp 11). Auch hier mussenwir nicht zwingendaller Welt erlauben,dieseNachrichtvonunszuempfangen,esreichtunserProvider.# ICMP-Typ 11 erlauben (ausgehend nur an unseren Provider)ipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE11 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 11 -d $MY_ISP -j ACCEPTDie wichtigstealler ICMPNachrichtenwird im Programmping benutzt.Mit Hilfe die-sesProgrammskannfestgestelltwerden,ob ein andererComputeruberdasNetz zu er-reichenist, odernicht. Der suchendeComputerschicktan dengesuchtenComputereinecho-request (ICMPTyp 8). Wennder gesuchteRechnerdiesesPaket empfangt,soschicktereinecho-reply (ICMPTyp 0 oderauchpong)zuruck.Ublich ist es,dawir jedenHostim Internetanpingendurfen,alsogehenTyp 8 PaketerausundTyp 0 Paketerein:# Ausgehendes Ping erlaubenipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 8 -d $ANYWHERE-j ACCEPTipchain -A input -i $EXTERNAL_INTERFACE-p icmp\6.4. PRAKTISCHERAUFBAU EINERFIREWALL 41-s $ANYWHERE0 -d $IPADDR -j ACCEPTWiederumalsBeispieleinereingeschranktenZulassungvon auen,erlaubenwir nur denRechnernunseresProviders,unsanzupingen:# Ankommendes Ping nur f ur Provider erlaubenipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $MYISP 8 -d $IPADDR -j ACCEPTipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 0 -d $MYISP -j ACCEPTDamit sind die notwendigenICMPNachrichtenerlaubt,die unnotigenverhindert.Jetztkonnenwir unslangsamandieechtenNetzwerkdiensteheranwagen.. .6.4.5 Diensteauf unpri vilegierten PortsDienste,dieaufunprivilegiertenPortslaufen,erschwerendenAufbaueinerFirewall erheb-lich. UnprivilegiertePortshabeneineDoppelbedeutung,einerseitskonnenDienstediesePortsnutzen,andererseitskonnenClients,die andereDienstenutzen,auf diesePortnum-mernzuruckgreifen(sieheSeite15).Mit dem TCPTransportprotokoll ist dieseDoppelbedeutungkein Problem,weil wir jaanhandder Steuerflags(SYN und ACK) unterscheidenkonnen,ob dasPaket von einemClient odervon einemServer stammt.Schwierigerwird esmit UDP. Aber einsnachdemanderen,schauenwir zunachstmalein paarTCPDienstean:HaufigeTCPDiensteauf unpri vilegierten PortsEin typischesBeispielist einOpenWindow DisplayServer(TCPPort2000).AusgehendeVerbindungenzueinemsolchenServersolltemansperren.Mit Hilfe derOption-y formu-lierenwir dieseRegelso,dasienurfur denAufbaueinerVerbindungeineslokalenClientszu einemfremdenServer gilt. FremdeCleients,die zufallig denPort2000nutzen,um miteinemunsererServer in Verbindungzu treten,sind von dieserRegel alsonicht betroffen.Genausowenigmussenwir eingehendeVerbindungswunscheblockieren,dennLinux bietetkeinenOpenWindow DisplayServeran.# Open Window Verbindungsaufbau sperrenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-s $IPADDR -d $ANYWHERE2000 -j REJECTBei X11-DisplayServernsiehtdie Sacheahnlichaus,jedochmussenwir hier auchein-gehendeVerbindungenunterbinden.AusgehendeVerbindungenwerdenausSicherheits-grundenverboten,weil X11 grundsatzlichaucheinensicherensshEingangbietet,derim-mer vorzuziehenist. X11DisplayServer benutzendie Ports6000bis 6063.Auf einemRechnerkonnenalsobis zu64Server laufen.Ein typischerFall einesPortbereichs.# X11 Aufbau zu einem fremden Server verbietenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-s $IPADDR -d $ANYWHERE6000:6063 -j REJECT# X11 Aufbau von auen zu einem unserer Server verbietenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\-d $IPADDR 6000:6063 -j DENY -l42 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUXUDPDiensteauf unpri vilegierten PortsUDP bietet viel wenigerInformation fur dasBetreibeneinerFirewall, als TCP. Wir ha-benkeinerleiAnhaltspunkt,ob ein Paket eineClientAnfrageodereineServerAntwortist. Dasist naturlich geradebei denunprivilegiertenPortseinegroeGefahr. Aus diesemGrundsolltenwir UDPganzlichsperrenundnureinzelneVerbindungenzuganzbestimm-tenRechnernzulassen.Im unprivilegiertenBereichspieltzumGlucknureinwichtigerUDPDiensteinerolle,dasNetwork File SystemNFS.NFSbenutztdenPort2049.NFSlasstsichzwar auchfur TCPkonfigurieren,aberdasist wesentlichunublicher, auchbeiTCPbenutztesdenPort2049.In der Regel wird NFS ausschlielichim LAN benutzt,eineFirewall sollte eseigentlichselbstnicht brauchen.Wir sperrenalsodieNFSDienstevollig:# NFS (2049) uber UDP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p udp\-d $IPADDR 2049 -j DENY -l# NFS (2049) uber TCP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\-d $IPADDR 2049 -j DENY -lipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-d $ANYWHERE2049 -j DENY -l6.4.6 Wichtige DiensteerlaubenNachdemunsereFirewall jetzt soweit konfiguriert ist, konnenwir uns an die eigentlichwichtigeArbeit machen,die jeweilig benotigtenDienstezuzulassen.Im folgendensindnurein paarBeispielegenannt,die wirlich wichtig sind.Im AnhangabSeite90 sinddie not-wendigenInformationenzudenwichtigstennotwendigenProtokollenzusammengestellt.DNSOhneDNSServerdienstewaredasInternet undwohl heuteauchdie meistenIntranetsnicht zu gebrauchen.DNS ist alsoein Dienst,auf denwir keinesfalls verzichtenkonnen.Normalerweiselaufenalle DNSAnfragenuberUDP, nur wenneineAntwort zu grofurein UDPPaket ware,schicktderServerein gekurztesPaket andenClient zuruck,woraufderClient die gleicheAnfragenochmaluberTCPversuchenkann.In derPraxiswird dasseltenbenotigt. Fur denAbgleichderDatenzwischenprimarenundsekundarenNameser-verneinerZone(demsogenanntenZoneTransfer)wird allerdingsimmerTCPbenutzt.UmalsoPaketedurchunsereFirewall zu lassen,die eineUDPAnfragebei unseremprimarenNameserverzugestatten,beschrankenwir unsaufdieseeineIPAdressedesNameservers:# DNS IP Adresse:NAMESERVER=xx.xx.xx.xx# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT6.4. PRAKTISCHERAUFBAU EINERFIREWALL 43Damit dasGanzeauch uber TCP funktioniert, insbesondere,damit ein eventuellerSe-kundarservereinenZoneTransferdurchfuhrenkann,benotigenwir nochzweiweitereRe-geln,diesmalfur TCP:# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPTBeachtenSiehierdie Angabe! -y , diebesagt,dadasACKFlaggesetztseinmu.Wenn wir jetzt aberselbsteinenNameserver betreiben,und der in der Lage sein mu,sichmit einemubergeordnetenNameserver zu unterhalten,dannbrauchenwir nocheinenweiterenSatzRegeln.DieseKommunikationzwischenzwei Nameservernfindetnamlich standardmaig auf demPort53 statt undzwar bei beidenKommunikationspartnern!Bisherhattenwir ja immernur KommunikationzwischeneinemunprivilegiertenPortmitdemPort53 desServerszugelassen.Also los:#DNS Forwarding (Server zu Server)ipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53 \-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR 53 -j ACCEPTDie letzteForm, die wir fur DNS nochbesprechenmussen,ist die Frage,ob auchClientsvon auerhalbauf unserenNameserver zugreifendurfen sollen.Das ist nur dannnotig,wenn wir tatsachlich eine echteDomain mit autoritativen Nameserver betreiben.In derRegel werdenwir denZugriff auf einenbestimmtenKreis von IPAdressenbeschranken.Nennenwir diesenKreis malMYDNSCLIENTS.# DNS Zugriff fremder ClientsMYDNSCLIENTS=ww.xx.yy.zz/mmipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53\-d $MYDNSCLIENTS$UNPRIVPORTS-j ACCEPT# DNS Forwarding f ur fremde Clientsipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53 \-d $MYDNSCLIENTS53 -j ACCEPT44 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUXipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS53 \-d $IPADDR 53 -j ACCEPTFur densehrunwahrscheinlichenFall, daSie einenZoneTransfervon auenzulassenwollen,gibt esnochdie Moglichkeit, auchdiesenmit Regelnzuzulassen.Allerdingssoll-ten wir hier die Liste der Clients, die diesenZoneTransferausfuhrendurfen wirklichnur auf die existierendenSekundarenServer von auenbeschranken,die diesenTransfertatsachlichbrauchen.Sonstkannjederalle DNS InformationenunsererDomaneeinfachfrei Hausbekommen...# DNS Zone-Transfer fremder ClientsMYDNSZONECLIENTS=ww.xx.yy.zz/mmipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $MYDNSZONECLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $MYDNSZONECLIENTS$UNPRIVPORTS-j ACCEPTDer identdServiceDer identd Dienst(manchmalauchauth genannt)lauft auf dem TCPPort113. Erist fur viele anderenDienstezwingendnotwendig,etwa fur dasVersendenvon E-Mail.Der Server unseresRechnersstellt dabeiInformationenubereinenbestimmtenUserzurVerfugung,etwa,ob esdiesenUseruberhauptgibt.. . .WennunserRechnereinenFTPoderMailserverbetreibt,dannfungiertergleichzeitigim-merauchalsauthClient.Esgibt keinensicherheitsrelevantenGrund,warumunserRech-nersocheAnfragennicht stellendurfte,alsolassenwir solcheAnfragenzu:# abgehende auth-Anfragenipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE113 \-d $IPADDR $UNPRIVPORTS-j ACCEPTOb wir diesenDienst tatsachlich auchanbietensollen, ist Ansichtssache.Wennwir unsentscheiden,diesenDienstzu aktivieren(in /etc/inetd.conf),dannbrauchenwir die beidenfolgendenRegeln,damiter funktioniert:# ankommende auth-Anfragenipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 113 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\6.4. PRAKTISCHERAUFBAU EINERFIREWALL 45-s $IPADDR 113 \-d $ANYWHERE$UNPRIVPORTS-j ACCEPTSolltenwir unsgegendiesenDienstentscheiden,soist esin diesemeinzigenFall gunstiger,dasPaketmit REJECTstattmit DENY zubehandeln.AnsonstenentstehenhoheTimeoutWartezeiten.Also:# ankommende auth-Anfragen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE\-d $IPADDR 113 -j REJECTDie weiterenDienste,die wir vielleicht aktivieren wollen, konnenjetzt anhandder Be-schreibungenim Anhangab Seite90 aufgebautwerden.DasgrundlegendePrinzip einerFirewall sollte jetzt klar gewordensein.Allerdingshat unsereFirewall bishernocheinenNachteil, der sie eindeutigin die AmateurKlasseverweist.Sie schutzt im Augenblicknamlichnur sichselbst.In dennachstenKapitelnwerdenwir dasandern.. .Um unsereersteFirewall zu aktivieren,mudasScript,daswir geradeerstellthabennurnoch ausfuhrbargemachtwerdenund aufgerufenwerden.Die Firewall lauft. Naturlichsollte dasin einemautomatisiertenStartScript je nachverwendeterDistribution ge-schehen.Kapitel 7Die Fir ewall als Router insInter netHeutesindlokaleNetzeetwasselbstverstandlichesgeworden,sowohl dieKostenfur solcheNetzehabensich dramatischnachuntenbewegt, als auchdasWissen,dasnotig ist, umComputerzuvernetzenist allgemeingestiegen.AusdieserVerbreitungvonlokalenNetzenfolgertsehrschnellderWunsch,daeinlokalesNetzeinenAnschluansInternetfindet,ohnedajederRechnerubereinModemodereineISDN-Verbindungverfugenmu.EsexistiereneinigeLosungsansatzefur diesesProblem,diezunachsteinmalkurzdargestelltwerdensollen:7.1 Router oder ProxyDie Begriffe Routerund Proxy werdengerneund oft falschoderzumindestensunscharfbenutzt.Dabeihandeltessich in beidenFallenum technischeLosungenfur dasProblemder AnbindungeineslokalenNetzesan dasInternet.Der Losungsansatzfindet jedochanvollig verschiedenenStellenstatt.7.1.1 Die ProxyTechnikProxieswurden schonrelativ fruh eingesetzt,als Betreibervon einzelnenNetzenoderInternetProvidergemerkthatten,damancheWebSeitensehrhaufigaufgerufenwurden.Dasfuhrtezu der Idee,daeinelokale Zwischenspeicherungdieserhaufig aufgerufenenWebseitendenDatenverkehrim Internetbzw. in derAnbindungzumInterneterheblichre-duzierenkonnte.DennanstatteineSeitepro Tag x mal uberdieseInternetanbindungzutransportieren,wurdesie nur nocheinmalgeholt, lokal zwischengespeichertund fallsjemanddie AdressedieserSeiteaufrief von diesemlokalen Zwischenspeicherherausausgeliefert.Dasheit,ein ProxyServer ist eineArt Webserver, der einenlokalenZwischenspeicherfur Webseitenbereithalt undeingehendeAnfragenan dasInternetentgegennimmt.Solltedie gewunschteSeiteschonlokal abgespeichertsein,so liefert er die gespeicherteSeitezuruck, ist sienochnicht gespeichert,soholt er sichdie SeiteausdemInternet,speichertsielokal zwischenundliefert siedannerstandenentsprechendenClient aus.467.1. ROUTERODERPROXY 47AnwendungTransportVermittlungNetzAnwendungTransportVermittlungNetzAnwendungTransportVermittlungNetzLAN InternetClient ServerProxyBild 7.1: Die ProxyTechnikDashatnundenNebeneffekt,daeinProxy, dereineInternetanbindunghat,denRechnernim lokalenNetzaucheinenZugriff, zumindestensfur WWWSeitenerlaubenkann,ohnedadie RechnerdeslokalenNetzesselbstZugangzum Internethaben.Sie erhaltenalleWebseitenja ebenvon diesemProxy. Der NachteildiesesVerfahrensliegt auf der Hand,einProxyarbeitetaufderAnwendungsschichtdesTCP/IPModellsundbietetnurFunktio-nalitatfur ein(odereinpaar)Protokoll(e).ModerneProxySystemegibt esetwafur WWWundFTP. DirekterInternetZugangist damitfur die Rechnerim Netznicht moglich.Wasauf denerstenBlick wie ein Nachteilaussieht,kannaberauchgenausogewunschtsein.So ist esvorstellbar, daein NetzbetreibereineslokalenNetzesgar nicht will, dajederRechnerim LAN bedingungslosenZugriff ins Internetbekommt.Die notwendigenDienste,wie Mail, WWW und FTP konnenuberProxieszur Verfugunggestelltwerden,andereDienste,wie etwaNetzspieleuberdasInternetsindsonicht moglich.7.1.2 Die RouterTechnikIm GegensatzzumProxyarbeitetein Router(oft auchGateway genannt)auf derVerbin-dungsschichtdesTCP/IPModells.Dasheit,er gibt Pakete,die er erhalt unddie nicht furihn bestimmtsind,von einemNetzwerkInterfacezu einemanderenweiter. Dabeiexistie-ren keineEinschrankungenhinsichtlich irgendwelcherProtokolle, dennProtokolle kenntderRouterja garnicht, fur ihn sindalle Paketenur IPPakete,egal wassieweiterenthal-ten.AnwendungTransportVermittlungNetzAnwendungTransportVermittlungNetzVermittlungNetzLAN InternetClient ServerRouterBild 7.2: Die RouterTechnikDie Arbeit einesRoutersim lokalenNetz,der zwei Netzemiteinanderverbindet,ist ein-fachzu verstehen.Dennder Routerkann ja klar sagen,welcheIPAdressezu welchem48 KAPITEL 7. DIE FIREWALL ALS ROUTERINS INTERNETNetzgehort undwelchesNetzanwelcherSchnittstellehangt.WasausdiesemSatzschonklar wird undwasein groerUnterschiedzumProxyist ist die Tatsache,daderRou-ter tatsachlichIPPaketeweiterleitet.Dasist in einemlokalenNetzweiter kein Problem,wir werdenabergleichsehen,daesim Zusammenhangmit demInternetsehrwohl zumProblemwerdenkann.Im weiterenVerlauf interessiertunsnaturlich die RouterTechnikim ZusammenhangmitderFirewall. Dabeiist esunsnaturlich unbenommen,auchProxyServereinzurichten,dieFunktionalitat derFirewall als Verbindungvom lokalenNetz ins InternetbasiertaberaufderWeitergabevon IPPaketen,alsoauf demRouting.7.2 DasProblemder reservierten Adr essenIn der gutenalten Zeit desInternets,als IPAdressennoch nicht knappwarenund dieRechner, die ansNetz wollten dasubereineStandleitunggetanhaben,war dasRoutingim Netzein Kinderspiel.War dochdamalsdie Situationdie, dajederansInternetange-schlosseneRechnereinefeste,einmaligeundvonuberallerreichbareIPAdressehatte.EinRouterhattealsonurnochdieAufgabe,einPaketandieentsprechendrichtigeSchnittstelleauszuliefernundschonwar alleserledigt.DieFirewall einesLinux RechnershatjanebendenbeidenRegelketteninput undoutputnochdie chain forward . DieseRegelkette ist speziellfur dasRoutinggedacht,dasoftauchmit demBegriff IPforwardingbezeichetwird. Die Zusammenhangederdrei KettensindausdemBild auf Seite32 zu entnehmen.Mit Hilfe dieserRegelketteist esalsoauchnochmoglich,zuentscheiden,welchePaketegeroutetwerdensollen.Heutejedochhabenwir eineKnappheitan IPAdressenund die lokalenNetzelaufeninder Regel mit den sogenanntenreserviertenAdressen.DiesereserviertenAdressensindim Internetnicht routbar. Dasheit,daselbstwenneinerunsererRechneransInternetangeschlossenist unddiesereineRechneraucheineechteIPAdresse1 hat,undnochdazualsRouterkonfiguriertist, eineVerbindungansInternetfur die anderenRechnernicht soohneweiteresmoglich ware.Die Rechnerim lokalenNetzhabenja IPAdressen,die imInternetnicht gultig sind.Selbstwennein IPPaket mit einersolchenungultigenAdressejemalseinenInternetServer erreichenwurde,so waredieserRechnernicht in der LageeineAntwort zuruckzuschicken,dennesexistierenkeineRoutenzu reserviertenAdressen wohin solltendie auchzeigen?Esgibt wahrscheinlichhundertevon lokalenNetzenaufderWelt, diedieseAdressenbenutzen.1Besser:einenicht reservierte,alsoroutefahigeAdresse7.3. MASQUERADING ALS PROBLEMLOSUNG 49Internet116.32.33.34194.135.17.199192.168.1.1192.168.1.2192.168.1.3192.168.1.4 192.168.1.5192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4192.168.1.5188.1.2.3 ! !"# #$% %&' '( () )* + +, ,- -. ./ / // / /0 0 00 0 01 12 23 3 34 4 45 5 55 5 56 6 66 6 67 78 89 9 9: : :; ; ;; ; ;; ; ;< >? ? ?@ @AAAAAABBBBBBCCCCCDDDDDEEEEEFFFFFBild 7.3: ReservierteAdressenim Internet7.3 MasqueradingalsProblemlosungDer LinuxKernelbieteteineLosungsmoglichkeit fur dieVerwendungreservierterAdres-senim Internetan,dassogenannteMasquerading.DabeiarbeitetderRouter, alsoderRech-ner, dersowohl amlokalenNetz,alsauchamInternethangt,alsMasqueradingServer. Die-serRechnerhatja eineechte,im InternetroutfahigeAdresse.Er nimmt jetztausdemloka-len NetzPaketeentgegenundverandertsiedergestalt,daim FeldderSenderIPAdressejetzt nicht mehr die reservierteAdressedeswahrenAbsenderssteht,sonderndie echteAdressedesMasqueradingServers.GleichzeitigmerktsichderMasqueradingServer dieOriginalAdressein einer KernelTabelle.Bekommt jetzt der MasqueradingServer dieAntwort ausdemInternet,so uberpruft er anhanddieserTabellen,fur wendieseAntwortwar, tauschtdie entsprechendenAdresenderPaketewiederum undgibt dassoveranderteAntwortpaketwiederandenRechnerim lokalenNetz,derdieAnfragelosgeschickthatte.Aus der Sicht desInternetServersexistiert alsogar kein lokalesNetz, er kommuniziertausschlielichmit demMasqueradingServer. Die AdressendeslokalenNetzessindmas-kiert.Dashatnaturlich denschonerwahntenVorteil,daAngriffeausdemInternetsowiesonuraufdenRouterstattfindenkonnen,niemalsdirektgegeneinenRechnerim lokalenNetz.DenndiesesNetzist nicht adressierbar!Auf der Ebenevon ipchains wird dasMasqueradinggenausobehandelt,als wareeseinePolicy. DiesePolicy ist aberlogischerweisenur fur die forward chaingultig. DasangegebeneNetzwerkinterface(-i beziehtsich immerauf dasexterneInterface,auf demdie realenAdressenmaskiertseinsollen.Sowird etwa durchdenBefehlipchains -A forward -i $EXTERNAL_INTERFACE-s 192.168.100.0/24 -j MASQ50 KAPITEL 7. DIE FIREWALL ALS ROUTERINS INTERNETdasMasqueradingfur dasNetz192.168.100.0aktiviert.DasobigeBeispielerlaubtgrundsatz-lich alleArtenvonDatenverkehr, naturlich konntenwir auchalleRegeltechniken,wie etwaPortsoderProtokolle hierbenutzen,eshandeltsichja tatsachlichum einePolicy. . .Die drei Regelketten input, forward und output werdenin dieserReihenfolgenacheinanderabgearbeitet.Dasbedeutet,danurdiejenigenPakete,diedurchdie input chaindurchkamen,anddie forward chainweitergegebenwerden.Und nur diejenigenPakete,die durchdieseKettekommenwerdenandie output chainweitergereicht.Erst,wenndasPaket auchdurchdieseKettedurchist, ohneausgesondertwordenzu sein,ge-langtestatsachlichins Internet.Fur ausdemInternetankommendePaketegilt dannwiederdasentsprechende.7.4 VerschiedeneModelle von routendenFir ewallsEine Firewall, die nicht nur sich selbstschutzt, wie die ausdemletztenKapitel, sondernauchgleichzeitigalsRouterfungiert,wird alsdual homedhostbezeichnet,alsoein Host,der in zwei Netzenzuhauseist. Mit dieserTechnik ist esmoglich, verschiedeneSicher-heitsstufenzu realisieren,je nachAnforderungdeszu schutzendenNetzes.Im FolgendenwerdendiebeidenwichtigstenModelledargestellt,dieBastionHostFirewall unddieDe-militarisierteZone(DMZ).7.4.1 Die BastionHostFirewallDie einfachste aberauchunsicherste Form einerroutendenFirewall ist die BastionHostFirewall. SiebestehtgrundsatzlichauseinemRechner, deralsdual homedhostzwi-schendemzuschutzendenNetzaufdereinenSeiteunddemunsicherenNetz(Internet)aufder anderenSeiteplaziert ist. DieserRechnerroutetPaketevon einemNetz ins andereob mit Masqueradingoderohne2. JedesPaket,dasdurchdiesenRechnergeroutetwerdensoll, mudiedrei RegelkettenderFirewall durchlaufen.Der Begriff Bastionstammtausdem Milit arischen,er kann aberauchwirklich so ver-standenwerden.Eine Bastionist eineVerteidigungseinrichtung,wennsie fallt, danngibteskeinenSchutzmehr. DieseAnalogiekannungebremstins Computernetubernommenwerden.Wenndie BastionHostFirewall geknacktwerdenwurde,dannlagedasgesamteNetzschutzlosda,derAngreifer, derdie Firewall uberwundenhatte,kanim LAN tun undlassen,waser will.Trotzdemist diesesModell fur die meistenkleinen Netzevollig ausreichend,wenndaszu schutzendeNetz nicht in groemMa selbstDiensteim Internetanbietensoll. In derRegel ist dasaberja auchgar nicht moglich, dennnormalerweisewurdenwir in diesemModell sowiesomit reserviertenAdressenim lokalenNetzarbeiten damithabenwir unsderMoglichkeit beraubt,selbstDiensteanzubieten.2Ohnenaturlich nurdann,wenndaszuschutzendeNetzechte,routfahigeIPAdressenbenutzt7.4. VERSCHIEDENEMODELLE VON ROUTENDENFIREWALLS 51InternetLokales (zu schtzendes) NetzBastionHostFirewallGHIJ KLM MNO O OO O OO O OP P PP P PP P PQ Q QR RS S ST TUUUUUUUUVVVVVVVBild 7.4: BastionHostFirewall7.4.2 Die Demilitarisierte Zone (DMZ)Erheblichsichererfur groeNetzeist dasModell der demilitarisiertenZone,manchmalauchPerimeterNetzwerkgenannt.DiesesModell trenntdaszu schutzendeNetz unddasoffentlichzugangigeNetznochmalaufundarbeitetfolgerichtigmit zweiFirewallRechnern.DaslokaleNetz,dasdieeigentlichenArbeitsplatzeverbindet,ist weiterhindaszuschutzen-de Netz. ZwischendiesemlokalenNetz und der bosengroenweitenWelt desInternetliegt jetztabernocheinNetz,diedemilitarisierteZone.Wir habenzweiFirewallRechner,einmalder BastionHost,der dasInternetmit der DMZ verbindet,und zum zweitendiesogenannteChokeFirewall. SieverbindetdaszuschutzendeNetzmit derDMZ. Innerhalbder DMZ stehenjetzt die Rechner, die von auerhalbzuganglichseinsollen.Also etwaderWebserver desUnternehmens,derFTPServer oderahnliches.Die RechnerderDMZmussendabeiabertatsachlichechte,routfahigeIPAdressenbesitzen,damitdiesesModellfunktioniert.52 KAPITEL 7. DIE FIREWALL ALS ROUTERINS INTERNETInternetLokales (zu schtzendes) Netzffentliche ServerChokeFirewallDemilitarisierte ZoneBastionHostFirewallWWXXYZ [[\\] ]^ ^_ _`a ab bc c cc c cd dd de ef fg g gh hi ii ij jj jk k kl l lm mn noooooopppppqqqqqqrrrrrrsssssttttttuuuuuBild 7.5: DMZ FirewallDieseForm der Firewall ist naturlich deutlich schwierigerzu verwirklichen,dafur aberauchwesentlichsicherer. Esexistiert kein einzigerKnackpunktmehr, andemalleinealleSicherheithangt.Der Ausfall bzw. die EroberungeinesElementsalleinefuhrt nochnichtzurUnsicherheitdeszuschutzendenNetzes.Im nachstenKapitelwerdenwir detailierteinesolcheFirewall3 aufbauen.3Wennhier voneinerFirewall die Redeist, dannmeintdieserBegriff nichtdie einzelnenRechner, dennFire-wallrechnerhabenwir ja zweiin diesemFall. Hier meintderSingularalsodieGesamtheitdesSicherheitssystems,bestehendausBastionFirewall, DMZ undChokeFirewall.Kapitel 8ExemplarischerAufbau einerDMZFir ewallUm die Komplexitat desAufbauseinerFirewall mit DMZ amStuck darzustellen,werdenwir in diesemKapiteleinekomplettesolcheFirewall aufbauen.ZunachsteinmalabernochetwasBegriffsklarungfur dasProjekt:Bastion DerRechner, derdasInternetmit derDMZ verbindet.Choke Der Rechner, derdaszuschutzendeNetzmit derDMZ verbindet.DMZ Die demilitarisierteZone,dasNetzzwischendemInternetunddemzuschutzendenNetz.LAN DaszuschutzendeNetz.Wir gehenalsodavon aus,daBastionund Choke beideals Gateway (dual homedhost)zur DMZ dienen.Die DMZ enthalt offentlicheundhalboffentlicheServer. JedesNetzwer-kinterfaceder beidenFirewallRechner(Bastionund Choke) besitzteigene,individuelleRegeln.Wir benotigenalsomindestensvier Regelsatze,je einenfur dasexterneundinter-ne InterfacebeiderMaschinen.Die Regeln fur dasexterneInterfacederBastionsind fastidentischmit denenausdemBeispielausdemAbschnitt6.4(Seite34).Die wirklichen NeuigkeitendiesesKapitelsbeziehensich hauptsachlichauf die Schnitt-stellenzurDMZ, alsodie interneSchnittstellederBastionunddieexterneSchnittstellederChoke.DieseRegelnverhaltensichspiegelbildlichzueinander. Fur die offentlichenServerinnerhalbderDMZ muesnocheinpaarseparateRegelngeben,wir gehenaberin diesemBeispieldavon aus,daessichhierbeium spezialisierteRechnerhandelt,die jeweils nureinenDienstanbietenunddahersehreinfacheRegelnbenotigen.Um den Rahmenund die Ubersichtuber diesesKapitel nicht zu gefahrden,werdenin-nerhalbdesKapitelsVereinfachungenzugelassen.Weil die externenRegeln der Bastionpraktischidentischsind mit denenausAbschnitt 6.4, werdenhier nur die Unterschiededargestellt.Im AnhangabSeite78 sinddie beidenScriptsfur BastionundChoke jedochbeidenocheinmalvollstandigabgedruckt.5354 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALLInternetLokales (zu schtzendes) Netzffentliche ServerDemilitarisierte Zone192.168.1.0192.168.5.0192.168.1.1192.168.1.2192.168.5.1eth1eth0eth1ChokeBastion123.45.67.89eth0v vv vw ww wxxyyz z{| |} ~ ~ Bild 8.1: Der AufbaudesBeispielsDasexterneInterfaceder Bastionliegt auf der Schnittstelleeth0 und hat die echteIPAdresse123.45.67.89zugewiesen.DasinterneInterfaceliegt auf eth1 undhatdie reser-vierteAdresse192.168.1.1Die DMZ hatdie192.168.1.0alsNetzwerkadresse.Die Choke hatihr externesNetzamInterfaceeth0 unddort die Adresse192.168.1.2,ihrinternesNetzliegt auf eth1 undbekommtdieAdresse192.168.5.1DasLAN hatdie Netzadresse192.168.5.0alsNetzwerkadresse.8.1 Die symbolischenKonstantenEin Firewallscript lasstsich grundsatzlich leichter lesenund hauptsachlich flexibler anVeranderungenanpassen,wenn wir nicht bei jeder Regel erneutdie IPAdressenange-ben,sondernam AnfangsymbolischeKonstantendefinieren,die wir im weiterenVerlaufdannbenutzen.Dasist immerdaserste,wasbeimAufbauneuerScriptszubeachtenist unddaherhaltenwir unsandieseVorgaben:8.1.1 Die Konstantenfur die Bastion# KonstantendefinitionEXTERNAL_INTERFACE=eth0 # Das Interface ins InternetIPADDR=123.45.67.89 # Adresse des InternetzugangsMY_ISP=123.45.67.90/16 # Der Bereich meines Providers8.2. WEITEREGRUNDEINSTELLUNGEN 55BASTION_DMZ_INTERFACE=eth1 # internes InterfaceBASTION_DMZ_IPADDR=192.168.1.1 # Adresse dazuLOOPBACK_INTERFACE=lo # Local LoopbackLOOPBACK=127.0.0.0/8 # Loopback-AdressbereichCHOKE_DMZ_IPADDR=192.168.1.2 # ext. Interface der ChokeDMZ_ADDRESSES=192.168.1.0/24 # IP-Bereich der DMZDMZ_BROADCAST=192.168.1.255 # Broadcastadresse DMZANYWHERE=any/0 # Jede IP-AdresseCLASS_A=10.0.0.0/8 # Reservierter Bereich Klasse ACLASS_B=172.16.0.0/12 # Reservierter Bereich Klasse BCLASS_C=192.168.0.0/16 # Reservierter Bereich Klasse CCLASS_D=224.0.0.0/4 # Komplette Klasse DCLASS_E=240.0.0.0/5 # Komplette Klasse EBROADCAST_SRC=0.0.0.0 # Broadcast AbsenderBROADCAST_DEST=255.255.255.255 # Broadcast EmpfangerPRIVPORTS=0:1023 # Privilegierte PortnummernUNPRIVPORTS=1024:65535 # Unprivilegierte Portnummern8.1.2 Die Konstantenfur die Choke#KonstantendefinitionCHOKE_DMZ_INTERFACE=eth0 # externes Interface der ChokeCHOKE_DMZ_IPADDR=192.168.1.2 # externe Adresse der ChokeCHOKE_LAN_INTERFACE=eth1 # internes Interface der ChokeCHOKE_LAN_IPADDR=192.168.5.1 # interne Adresse der ChokeLOOPBACK_INTERFACE=lo # Local LoopbackLOOPBACK=127.0.0.0/8 # Loopback-AdressbereichBASTION_DMZ_IPADDR=192.168.1.1 # interne Adresse der BastionDMZ_ADDRESSES=192.168.1.0/24 # IP-Bereich der DMZLAN_ADDRESSES=192.168.5.0/24 # IP-Bereich des LANDMZ_BROADCAST=192.168.1.255 # Broadcastadresse DMZANYWHERE=any/0 # Jede IP-AdresseCLASS_A=10.0.0.0/8 # Reservierter Bereich Klasse ACLASS_B=172.16.0.0/12 # Reservierter Bereich Klasse BCLASS_C=192.168.0.0/16 # Reservierter Bereich Klasse CCLASS_D=224.0.0.0/4 # Komplette Klasse DCLASS_E=240.0.0.0/5 # Komplette Klasse EBROADCAST_SRC=0.0.0.0 # Broadcast AbsenderBROADCAST_DEST=255.255.255.255 # Broadcast EmpfangerPRIVPORTS=0:1023 # Privilegierte PortnummernUNPRIVPORTS=1024:65535 # Unprivilegierte Portnummern8.2 WeitereGrundeinstellungenWie ublich loschenwir zunachsteinmal in beidenScripts(fur Choke und Bastion)diebisherbestehendenRegeln.Dasist nur eineSicherheitsmanahme,um zu vermeiden,da56 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALLeventuellexistierendeRegeln,die vor demAufruf desScriptserstelltwurden,nicht weitergelten.In beidenScriptsstehtalsojetzt# Alle bestehenden Regeln l oschenipchains -FDie Chainssind jetzt geloscht,nicht jedocheineeventuellbestehendePolicy. Also defi-nierenwir soforteineneue,die allesgrundsatzlichverbietet,wasnicht explizit erlaubtist.Hier machenwir abereinenUnterschiedzwischenBastionundChoke.Die Bastionarbei-tet grundsatzlichmit DENY, gibt alsokeinerleiRuckmeldungenzuruck,auerins interneNetz,alsodie DMZ. Dasist wichtig, weil solcheRuckmeldungeneinempotenziellenAn-greiferschonbestimmteDingemitteilenkann.Die Chokejedocharbeitetin einemUmfeld,daswesentlichmehrVertrauenvon unsverdient.Hier arbeitenwir mit REJECT, um Feh-lermeldungenzuerzeugenundTimeoutWartezeitendadurchzuvermeiden.DasScriptderBastionerhalt alsofolgendenEintrag:# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECTwahrenddieChoke uberallmit REJECTarbeitet:# Voreingestellte Policies setzenipchains -P input REJECTipchains -P output REJECTipchains -P forward REJECTAn diesemPunkt sind alle Regeln geloschtund alle Policiesauf DENY oder REJECTgesetzt.Esist keinerleiNetzverkehrmehrmoglich.Wie im letztenBeispielsolltenwir jetztzunachstwiederdasLoopbackDeviceermoglichen,dort sindAngriffe nicht moglich, esdrohtkeinerleiGefahr, wir lasseneinfachallesauf diesemDevice zu. Dasgilt wiederfurbeideMaschinen,BastionundChoke:# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPTEs kannauchnicht schaden,wennwir an dieserStellewiederbei beidenMaschinendieKerneleigenenSchutzroutinenaktivieren,wie wir dasauchschonim Abschnitt6.4.2ge-machthatten.Dort ist esschonerklart,daherhier nur nochdieentsprechendenAnweisun-gen:# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdoecho 1 > $i8.2. WEITEREGRUNDEINSTELLUNGEN 57doneJetztfiltern wir wiederdie Adressenaus,die offensichtlichungultig sind. ZunachstmalwiederjeweilsdieeigenenAdressen.Die BastionFirewall bekommtalsodieAnweisungen# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammenipchains -A input -i $EXTERNAL_INTERFACE\-s $IPADDR -j DENY -lipchains -A input -i $BASTION_DMZ_INTERFACE\-s $BASTION_DMZ_IPADDR-j DENY -lwahrenddieChoke folgendeZeilenbraucht:# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammenipchains -A input -i $CHOKE_LAN_INTERFACE\-s $CHOKE_LAN_IPADDR-j REJECT -lipchains -A input -i CHOKE_DMZ_INTERFACE\-s $CHOKE_DMZ_IPADDR-j REJECT -lBei derBastionbelassenwir dieFilterungderrestlichenAdressenwie in unseremBeispielausAbschnitt6.4. Die Choke hingegenmunur AdressenausdemPool der reserviertenA undBKlassenaussondern,weil sieja selbstaufbeidenNetzwerkkarteneineCKlassereservierteAdressebenutzt.Nebenbeifiltern wir wie gehabtauchLoopbackund fehler-hafteBroadcastsaus.Die Angabedervon derIANA reserviertenAdressensparenwir unsfur dieChoke,dieBationhatsieja schon.# Pakete mit privaten A-Klasse Adressen als Sender oder# Empfanger verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_A -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_A -j REJECT -lipchains -A output -i $CHOKE_DMZ_INTERFACE-d $CLASS_A -j REJECT -lipchains -A output -i $CHOKE_LAN_INTERFACE-d $CLASS_A -j REJECT -l# Pakete mit privaten B-Klasse Adressen als Sender oder# Empfanger verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_B -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_B -j REJECT -lipchains -A output -i $CHOKE_DMZ_INTERFACE-d $CLASS_B -j REJECT -lipchains -A output -i $CHOKE_LAN_INTERFACE-d $CLASS_B -j REJECT -l# Pakete mit D-Klasse Adressen als Sender verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_D -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_D -j REJECT -lipchains -A output -i $CHOKE_DMZ_INTERFACE-s $CLASS_D -j REJECT -lipchains -A output -i $CHOKE_LAN_INTERFACE-s $CLASS_D -j REJECT -l# Pakete mit E-Klasse Adressen verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_E -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_E -j REJECT -l# Pakete mit Loopback Adressen als Sender verwerfen58 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALLipchains -A input -i $CHOKE_DMZ_INTERFACE-s $LOOPBACK-j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $LOOPBACK-j REJECT -l# Pakete mit fehlerhaften Broadcast Adressen verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE\-s $BROADCAST_DEST-j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE\-s $BROADCAST_DEST-j REJECT -lipchains -A input -i $CHOKE_DMZ_INTERFACE\-d $BROADCAST_SRC-j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE\-d $BROADCAST_SRC-j REJECT -lDamit hattenwir die Grundeinstellungbei beidenScriptserledigt. Jetztgeht es an dieeigentlicheArbeit, versprichtaberauchinteressanterzuwerden.8.3 ICMPNachrichten filter nDie Bastionhat schonRegeln fur ICMPNachrichten,die sich bisherabernur auf dieexterneSchnittstelle,alsoauf die Schnittstelleins Internetbeziehen.DieseRegeln lassenwir wie gehabt,fugenabernochein paarRegeln fur die Kommunukationmit der DMZhinzu.Hier wird dasersteMal die SymetriezwischendeminternenInterfacederBastionunddemexternenderChokesichtbar.8.3.1 SourceQuenchNachrichtenDie ICMPNachrichtenvom Typ 4 (source-quench ) werdenerstellt,wennein Kom-munikationspartnermit derGeschwindigkeiteinesanderennichtmehrmithaltenkann,weilz.B.seineinternenBuffervoll sind.BastionundChokeakzeptierenallesource-quenchNachrichten,diebei derKommunikationmit derDMZ entstehen.Die Befehlefur die Bastion# source-quench zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR4 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES4 -d $BASTION_DMZ_IPADDR-j ACCEPTDie Befehlefur die Choke# source-quench zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES4 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR4 -d $DMZ_ADDRESSES-j ACCEPTSichtbarwird hier, dadie Regeln fur Bastionund Choke sehrahnlich sind, aberebennur die fur die interneBastionSchnittstelleunddie derexternenChoke Schnittstelle.Dasist logisch,denndiesebeidenSchnittstellentransportierenja die InformationspaketevomLAN ins Internet.8.3. ICMPNACHRICHTENFILTERN 598.3.2 ParameterProblem NachrichtenDieseNachrichtenpakete(Typ 12)werdengesendet,wenneinPaketempfangenwurde,dasungultige Datenim Headeraufweist.Auch dieseNachrichtenlassenwir fur die Kommu-nikationmit derDMZ grundsatzlichdurch.Die Befehlefur die Bastion# parameter-problem zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $ANYWHERE12 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES12 -d $ANYWHERE-j ACCEPTDie Befehlefur die Choke# parameter-problem zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $ANYWHERE12 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR12 -d $ANYWHERE-j ACCEPT8.3.3 DestinationUnreachableNachrichtenDieserNachrichtenpakettyp(Typ 3) ist eineallgemeineFehlermeldung.AuchdieseNach-richtenlassenwir fur dieKommunikationmit derDMZ grundsatzlichdurch.Die Befehlefur die Bastion# destination-unreachable zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $ANYWHERE3 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES3 -d $ANYWHERE-j ACCEPTDie Befehlefur die Choke# destination-unreachable zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $ANYWHERE3 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR3 -d $ANYWHERE-j ACCEPT8.3.4 TimeExceededNachrichtenDieseNachrichtenpakete(Typ 11)zeigenan,daeinPaketzuoft geroutetwurde,daseineLebensdauerauf 0 gesunken ist. Es wird aberauchals Antwort fur Traceroutebenutzt.Auch dieseNachrichtenlassenwir fur die Kommunikationmit der DMZ grundsatzlichdurch.60 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALLDie Befehlefur die Bastion# time-exceeded zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR11 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES11 -d $BASTION_DMZ_IPADDR-j ACCEPTDie Befehlefur die ChokeDie Chokedarf nurmit derBastionNachrichtenvom Typ time-exceed austauschen.# time-exceeded zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR11 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR11 -d $BASTION_DMZ_IPADDR-j ACCEPT8.3.5 Ping KonfigurationDerBefehlping verwendetzweiunterschiedlicheNachrichtentypen,jeweilsfur Anfragen(echo-request Typ 8) undAntworten(echo-reply Typ 0).ping Konfiguration der BastionAlle RechnerderDMZ durfenins Internetpingen:# Ausgehendes Ping aus der DMZipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES8 -d $ANYWHERE-j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $ANYWHERE0 -d $DMZ_ADDRESSES-j ACCEPTAndersherumdarfabernurdieBastionselbstRechnerin derDMZ anpingen:# Ankommendes Ping in die DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR8 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES0 -d $BASTION_DMZ_IPADDR-j ACCEPTping Konfiguration der ChokeDie Chokedarf jedenRechnerim Internetanpingen:# Ausgehendes Ping ins Internetipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR8 -d $ANYWHERE-j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $ANYWHERE0 -d $CHOKE_DMZ_IPADDR-j ACCEPT8.4. DIENSTEAUF UNPRIVILEGIERTEN PORTS 61AnkommendePingssindjedochnurausderDMZ gestattet.# Ankommende Pings aus der DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES8 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR0 -d $DMZ_ADDRESSES-j ACCEPT8.4 Diensteauf unpri vilegierten PortsDie Diensteauf denunprivilegiertenPortslassenwir auf der Bastionso, wie wir sie imAbschnitt 6.4 formuliert hatte.Die Choke mu dieseDiensteuberhauptnicht beachten,dennes warenja nur Verboteausdem globalenNetz. Von auendroht uns also keineGefahrmehr.Wir brauchendieseDienstenichtvomLAN in dieDMZ weitergebenunddagrundsatzlichallesverbotenist, wasnicht explizit erlaubt,benotigenwir keineRegeln mehr. InnerhalbdesLAN stehensieunsnaturlich weiterzur Verfugung.Dort werdenPaketeja nicht gefil-tert,sondernnurweitergegeben.8.5 Domain NameServiceDas DNSSystem(TCP und UDPPort53) ist heutefur eine Zugriff auf dasInternetvon zwingenderBedeutung.OhneNameserver musstendie IPAddressender einzelnenServer im Internetbekanntsein,dasist mehroderwenigerunmoglich. Alle RechnerdesLAN mussenalsoZugriff auf einenNameserver haben.Dabeigibt esaberverschiedeneMoglichkeiten,diehier kurzbeschriebenwerdensollen.8.5.1 Nutzung einesoffentlichen NameserversDie einfachsteForm ist die, daein offentlicherNameserver im Internet,etwa der IhresProvidersbenutztwird. In diesemFall muder Choke nur mitgeteilt werden,daDNSAnfragendurchgelassenwerden,so wie wir dasauchschonim Beispiel in Abschnitt6.4getanhaben.Die Bastionbehalt die Zeilen ausdemgenanntenBeispielebenfalls. Damitist ein Durchganggeschaffen,deralle notwendigenDNSDiensteermoglicht. Die Chokeerhalt alsodie Zeilen:# DNS IP Adresse:NAMESERVER=xx.xx.xx.xx# UDP-Nameserverzugriffipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp\-s $NAMESERVER53 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# TCP-Nameserverzugriffipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp\-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\62 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALL-d $NAMESERVER53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPTWir werdenjaspaterdasMasqueradingaktivieren,daherreichtes,wenndieAdresseimmernurdie derChoke ist. Alle AdressendesLAN werdenja in dieseAdressemaskiert.8.5.2 BetreibeneigenerNameserverEin wesentlichkomplexeresVerfahrenbestehtdarin,eigeneNameserver zu betreiben.InunseremBeispielwurdesichdabei wennhoheSicherheiterwunschtist folgendesSze-narioanbieten:Auf derBastionlaufteinoffentlicherNameserver. Er ist konfiguriertalsautoritativerServerfur die Site,verfugt abernur uberunvollstandigeDaten.Er hat keineInformationenuberdie RechnerdesLAN, nur uberdie derDMZ. Die Programmeder Bastionselbstgreifennicht aufdiesenServerzu.Auf derChokelauftaucheinNameserver. DieserNameserverenthalt tatsachlichdierealenDatendesLAN undderDMZ. Alle ClientsausdemLAN greifenausschlielichauf die-senNameserver zu. Auch die Clientsder Bastion(die Programmeder Bastion,die einenDNSDienstbenotigen)greifenauf denServerderChoke zu.WennderChokeServerei-neAnfragenicht beantwortenkann,leitet er sieweiterandenServer derBastion,dersiewiederumaneinenexternenServer im Internetweitergibt.Fur dieseKonfigurationsindnaturlich aucherheblichkomplexereRegelnnotwendig.Konfiguration der Bastion als offentlicher Nameserver# Der DNS-Server der Bastion akzeptiert Anfragen der Choke (UDP 53)ipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR53\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT# DNS Anfragen der Bastion an den Server der Choke (UDP/TCP 53)ipchains -A output -i $BASTION_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp\-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $CHOKE_DMZ_IPADDR53 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# DNS IP Adresse (Nameserver im Internet):NAMESERVER=xx.xx.xx.xx8.5. DOMAIN NAME SERVICE 63#DNS Forwarding (Server zu Server)ipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53 \-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR 53 -j ACCEPT# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# DNS Zugriff fremder Clientsipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPTKonfiguration der Choke alspri vater NameserverDerprivateNameserver liegt aufderChoke.ClientsausdemLAN undderBastiongreifenauf diesenServer zu. Wenner eineAnfragenicht beantwortenkann,dannleitet er sie andenServerderBastionweiter.Die Regeln fur die Choke verhaltensichgewissermaenspiegelbildlich zu denenderBa-stion.# Der DNS-Server der Choke gibt Anfragen an die Bastion (UDP 53)ipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR53\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT64 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALL# Der Nameserver der Choke l asst Anfragen aller Clients aus der# DMZ zu (TCP/UDP 53)ipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT8.6 Der identService (auth)DieserService(TCP113)wird von manchenInternetDienstenbenutzt,um NamenoderID einesbestimmtenUserszu erfragen.Das ist etwa bei fremdenMailservern der Fall,die Mails weitergeben.Es ist nicht zwingendnotig, selbsteinensolchenServer laufenzu haben,obwohl nichtsdagegenspricht.Auf jedenFall solltenwir eineFirewallRegelerstellen,um unnotigeTimeoutszu vermeiden.Fur unserBeispielwerdenwir davon ausgehen,dasowohl auf der Bastion,alsauchaufderChokesowohl Clients,alsauchServermit demauth Protokoll arbeiten.8.6.1 Konfiguration der Bastion# abgehende auth-Anfragen ins Internetipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE113 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# ankommende auth-Anfragen aus dem Internetipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 113 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 113 \-d $ANYWHERE$UNPRIVPORTS-j ACCEPT# Bastion als auth-Client nach innenipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp \-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $DMZ_ADDRESSES113 -j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $DMZ_ADDRESSES113 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT8.7. EMAIL 65# Bastion als Server nach innenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR113 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $BASTION_DMZ_IPADDR113 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT8.6.2 Konfiguration der Choke# Choke als auth Serveripchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR113 -j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $CHOKE_DMZ_IPADDR113 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT# Choke als auth-Clientipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp\-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $ANYWHERE113 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT8.7 EMailEsgibt naturlich auchnur fur unserModell eineVielzahlvon denkbarenKombinatio-nenfur EMail Empfangund Versand.Wir werdenhier exemplarischeineKombinationdurchspielen,die wahrscheinlichin der Praxisdie haufigsteist. Die Bastion,die ja eineechteIPAdressehat, sendetund empfangtMail mit SMTP (TCP 25). Die RechnerdesLAN holensichdieMails beiderBastionmittelsPOP3(TCP110)ab.Wir mussenalsoder BastionerlaubenSMTPPaketezu empfangenund zu senden,undweiterhinPOP-Anfragenzu empfangenundzu beantworten.Die Choke muauchSMTPdurchlassen,schlielichsendendie RechnerdesLAN ihre Mails ja mit SMTP. Sie muebenfallsPOPPaketedurchlassen,in beideRichtungen.8.7.1 AbgehendeMails uber die BastionverschickenHier habenwir zunachsteinmalzweiMoglichkeiten.Entwederwir schickenalleausgehen-de Mail an denMailserver unseresProvidersoderwir schickensiegleichan die entspre-chendenEmpfangerrechner. Die einfachereMoglichkeit ist die desProviderservers,weildersichdannum die korrekteWeiterleitungkummernmu.Die dazunotigenRegelnderBastionsind:# Mail uber SMTP an Provider Gateway# Zuerst der Name des GatewaysSMTP_GATEWAY=smtp.server.provider .beisp iel66 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALLipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $SMTP_GATEWAY25 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $SMTP_GATEWAY25 \-d $IPADDR $UNPRIVPORTS-j ACCEPTWennaberstattdessenerwunschtist, dadieBastionselbstMailserverist, alsodieMail di-rektzuverschicken,dannmueinfachstattderAngabedesSMTPGatewaysein$ANYWHEREverwendetwerden:# Mail uber SMTP an Provider Gatewayipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE25 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE25 \-d $IPADDR $UNPRIVPORTS-j ACCEPTDamitdieBastionaberauchankommendeAuftrageausderDMZ akzeptierenkann,bedarfesnocheinesweiterenRegelsatzesfur dasBastionScript:# Bastion nimmt SMTP Anfragen aus der DMZ entgegenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR25 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPTJetztmussenwir abernochderChoke erlauben,SMTP-Paketeandie Bastiondurchzulas-sen.In dasChokeScriptmufolglich eingetragenwerden:# Choke erlaubt SMTP-Pakete an die Bastionipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp\-s CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $BASTION_DMZ_IPADDR25 \-d CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPTDamit solltederVersandvon EMail auchfur die Rechnerim LAN moglichsein.8.7.2 Mailempfang uber POPServer auf der BastionDie RechnerdesLAN holenihre Mails direkt bei derBastionab. Dasgeschiehtmit demPOP3Protokoll (TCP 110). Die Bastionmunur Paketeausder DMZ durchlassen,ausdemInternetist dieserServicenichtverfugbar. DasBastionScriptbekommtalsonochdieRegeln:# POP-Server der Bastion nimmt Pakete aus der DMZ entgegen8.8. ALLE WEITERENDIENSTE 67ipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR110 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPTNaturlich mujetztauchwiederdieChokenochsoweit konfiguriertwerden,dasiePaketedurchlasst,die an die Bastiongerichtetsind. Das ChokeScriptwird um die folgendenRegelnerweitert:# POP3 Pakete an die Bastion werden weitergegeben:ipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp \-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR110 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT8.8 Alle weiteren DiensteDamit wir hier jetzt nicht jedendenkbarenInternetDienstin epischerBreite darstellenmussen,hiernocheinpaarallgemeingultigeTips zumAufbaudereinzelnenRegeln.Der grundsatzlicheAufbau der Regeln ist immer gleich, die BastionerlaubtbestimmtePakete,die Chokeerlaubtdie selbenPakete.Aber wahrenddie BastiondiePaketeauf ihreinterneSchnittstelleerlaubt,tut die Choke esauf die externe.Man konntefastvon einerArt Achsensymetriesprechen,dieAchsewarein demFall dieDMZ.Um die richtigenRegeln fur einenbestimmtenDienstzu erstellen,ist esnotwendig,einProtokoll hinlanglichzu verstehen.Dazukonnendie im AnhangaufgefuhrtenProtokoll-beschreibungendienen.DieseBeschreibungensind selbstverstandlich nicht vollstandig,daswurdedenRahmenderDarstellungsprengen.GenauereDetailskonnenin denjewei-ligen HOWTOS,denRFCsund anderenInformationsquellenentnommenwerden.Trotz-demsolltenachderDurcharbeitungderletztenAbschnittegenugendVerstandnisfur eigeneWeiterentwicklungenvorhandensein.8.9 LAN Zugriff auf die ChokeBei allenRegeln,diewir in denletztenAbschnittenaufgestellthaben,habenwir eineKlei-nigkeit einfachweggelassen.Wir habenzwar der Choke jeweils Regeln gegeben,die be-stimmtenPaketenerlauben,an die Bastionweitergeleitetzu werden,wir habenaberderChoke niemalseineRegel gegeben,die uberhauptPaketeausdemLAN entgegennehmenwurde.In derRegel stellt eskeinSicherheitsproblemdar, wenndie Chokealle PaketeausdemzuschutzendenNetz(LAN) akzeptiert,damitsparenwir unseineMengezusatzlicherRegeln,wennwir daspauschalfur dieChoke formulieren:# Vollst andige Offnung der Kommunikation zwischen LAN und Chokeipchains -A input -i $CHOKE_LAN_INTERFACE\-s $LAN_ADDRESSES-j ACCEPTipchains -A output -i $CHOKE_LAN_INTERFACE\-d $LAN_ADDRESSES-j ACCEPT68 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZFIREWALL8.10 Und schlielichdasMasqueradingBis zu diesemPunktderDarstellunghabenwederdie Bastion,nochdie Choke tatsachlichPaketemaskiert,ausdiesemGrundhatteauchein Datenverkehrmit demInternetbis jetztnochnicht funktionierenkonnen.In unsererDMZ und im LAN arbeitenwir ja mit reser-viertenAdressen.(Auchwennesin derPraxuswenigSinnmacht,dieDMZ wareja sovonauennicht ansprechbar)DerersteSchritt ist jetztalsoder, dawir dieBastionzumMasqueradingServererklaren,der alle Pakete,die von der Choke kommen,auf seineechteInternetAdressemaskiert.DasgesammteNetzwird sozumInternetkomplettversteckt.# Bastion maskiert alle Pakete der Chokeipchains -A forward -i $EXTERNAL_INTERFACE\-s $CHOKE_DMZ_IPADDRESS-j MASQDamit jetztaberauchallePaketeausdemLAN unterderAdressederChokeandieBastiongehen,mussenwir auchdie Choke als MasqueradingServer konfigurieren,die jetzt allePakete ausdem LAN mit ihrer DMZAdressemaskiert.Das bietet aucheine doppelteSicherheit,denninnerhalbderDMZ ist damitdasLAN unsichtbar, esexistiertnurnochdieChoke:# Choke maskiert alle Pakete des LANipchains -A forward -i $CHOKE_DMZ_INTERFACE\-s $LAN_ADDRESSES-j MASQAnhang AWichtige PortnummernA.1 Haufig gescanntePortsPort Dienst Protokoll Gefahr Bemerkung0 reserviert TCP/UDP hoch Sowohl als Absender, als auch alsEmpfangerportungultig0-5 TCP hoch Signaturvon sscan7 echo TCP/UDP hoch UDPAngriffsmoglichkeit11 systat TCP hoch InformationenuberlaufendeProzesse15 netstat TCP hoch AbfragedesNetzwerkstatus,offeneVer-bindungen,Routingtabellen,.. .19 chargen TCP/UDP hoch UDPAngriffsmoglichkeit20,21 ftp TCP mittel FTP-Zugriff, Dateitransfer22 ssh TCP mittel Secure Shell Eine sichere (ver-schlusselte)Moglichkeit desremotelo-gin22 UDP niedrig EinealteVersionvonPCAnywhere23 telnet TCP hoch TELNET UnverschlusselteMoglich-keit desremotelogin25 smtp TCP hoch SimpleMail TransferProtocol jemandsucht nach SpamRelayoder einer Si-cherheitslucke alterer sendmail Ver-sionen53 domain TCP hoch TCPZoneTransferoderFalschungvonDNSInformationen67 bootps UDP niedrig69 tftpd UDP mittel Unsichere(UDP)AlternativezuFTP79 finger TCP niedrig Informationenuber die User einesSy-stems87 link TCP hoch tty-link , gernevon Angreifern be-nutzt109,110 pop2/3 TCP hoch Post Office Protocol - Einer der dreihaufigstangegriffenenPorts111 sunrpc TCP/UDP hoch RemoteProcedureCall - Der haufigsteAngriffsportuberhaupt119 nntp TCP mittel Offentlicher Newsfeed(wird zum Ver-sendenvon Spambenutzt)TabelleA.1: HaufiggescanntePortnummernundihreBedeutung6970 ANHANG A. WICHTIGE PORTNUMMERNPort Dienst Protokoll Gefahr Bemerkung123 ntp UDP niedrig Zeitsynchronisationubers Netz - un-gefahrlichabervielleicht lastig137 netbios-ns TCP/UDP mittel Nameservicefur Windows Netze furUnix harmlos138 netbios-dgm TCP/UDP mittel Fur WindowsNetze fur Unix harmlos139 netbios-ssm TCP/UDP mittel Fur WindowsNetze fur Unix harmlos143 imap TCP hoch Internet Mail Protocol Der Nachfol-gervon POP3.EinerderhaufigstenAn-griffsziele161,162 snmp UDP mittel SimpleNetwork ManagementProtocolNetzwerkadministrationubersNetz177 xdmcp UDP hoch Login ManagerdesX-Window-Systems512 exec TCP hoch Remoteprocessexecution512 biff UDP hoch MailBenachrichtigung513 login TCP hoch RemoteLogin513 who UDP hoch Wer ist eingeloggt514 shell TCP hoch RemoteShell514 syslog UDP hoch SyslogEingang515 printer TCP hoch NetzwerkDrucker517 talk UDP mittel NetzwerkTelephon518 ntalk UDP mittel NetzwerkTelephon520 route UDP hoch RoutingTabellen540 uucp TCP mittel UUCPDienste635 mount UDP hoch Sicherheitslucke im Mountdaemon1114 tt SQL TCP hoch Signaturvon sscan2000 openwin TCP hoch OpenWindows2049 nfs TCP/UDP hoch Network File System Fernzugriff aufsDateisystem5632 pcanywhere UDP niedrig PCAnywhere6000+n X11 TCP hoch XWindowSystem12345 netbus TCP hoch NetBus,einTrojaner, derauchauf ande-renPortserscheinenkann(haufigsindet-wa 12346oder20034) fur Unix harm-los31337 backorifice UDP hoch NocheinTrojaner fur Unix harmlosTabelleA.2: HaufiggescanntePortnummernundihre Bedeutung(Fortsetzung)A.2. ICMP NACHRICHTENTYPEN 71A.2 ICMP Nachrichten TypenName: Nummer: Bemerkung:pong 0 Antwort auf Ping- auchecho-reply genanntdestination-unreachable 3 Fehlermeldung:Ein Router konnte das Paket nichtweitergebenundsendetdieseMeldungzuruck.source-quench 4 Flusskontrollezwischenzwei Rechnernredirect 5 Routeninformation.Ein Rechner kann mit dieserNachrichteinemanderenRechner(auf dementwederder routed oderder gated laufenmu)mitteilen,daeseinebessereRoutegibt.ping 8 Echoanforderung.Ein Rechner, der dieses Paketerhalt, schickt eine Kopie desPaketeszuruck. Auchecho-request genannttime-exceeded 11 Fehlermeldung:Paket wurdezu oft geroutet.DasLe-bensdauerfeldist auf 0parameter-problem 12 Fehlermeldung:Der Headerdes IPPaketes enthaltungultigeWerteTabelleA.3: ICMPNachrichtentypenAnhang BDie BeispielScriptsB.1 DasersteFir ewallscript# KonstantendefinitionEXTERNAL_INTERFACE=eth0 # Das fremde NetzLOOPBACK_INTERFACE=lo # Local LoopbackIPADDR=192.168.100.1 # Eigene AdresseANYWHERE=any/0 # Jede IP-AdresseMY_ISP=123.45.67.89/16 # Der Bereich meines ProvidersLOOPBACK=127.0.0.0/8 # Loopback-AdressbereichCLASS_A=10.0.0.0/8 # Reservierter Bereich Klasse ACLASS_B=172.16.0.0/12 # Reservierter Bereich Klasse BCLASS_C=192.168.0.0/16 # Reservierter Bereich Klasse CCLASS_D=224.0.0.0/4 # Komplette Klasse DCLASS_E=240.0.0.0/5 # Komplette Klasse EBROADCAST_SRC=0.0.0.0 # Broadcast AbsenderBROADCAST_DEST=255.255.255.255 # Broadcast EmpfangerPRIVPORTS=0:1023 # Privilegierte PortnummernUNPRIVPORTS=1024:65535 # Unprivilegierte Portnummern# Alle bestehenden Regeln l oschenipchains -F# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECT# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdoecho 1 > $idone# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammen72B.1. DAS ERSTEFIREWALLSCRIPT 73ipchains -A input -i $EXTERNAL_INTERFACE-s $IPADDR -j DENY -l# Reservierte A-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENY# Reservierte B-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENY# Reservierte C-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENY# Pakete mit Loopback als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENY# Pakete mit illegalen Broadcast Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $BROADCAST_DEST-j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $BROADCAST_SRC-j DENY# Pakete mit Klasse-D Adresse als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_D -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_D -j# Klasse-E Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_E -j DENY# Von der IANA reservierte Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s 1.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 2.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 5.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 7.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 23.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 27.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 31.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 37.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 39.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 41.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 42.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 58.0.0.0/7 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 60.0.0.0/8 -j DENY# 65 entspricht 01000001 - also wurde die Maske /3 leider die 64# mit ansprechen. Wir mussen daher 65-79 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 65.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 66.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 67.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 68.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 69.0.0.0/8 -j DENY74 ANHANG B. DIE BEISPIELSCRIPTSipchains -A input -i $EXTERNAL_INTERFACE-s 70.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 71.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 72.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 73.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 74.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 75.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 76.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 77.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 78.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 79.0.0.0/8 -j DENY# 80-95 l asst sich mit der Maske /4 ansprechenipchains -A input -i $EXTERNAL_INTERFACE-s 80.0.0.0/4 -j DENY# 96-111 l asst sich mit der Maske /4 ansprechenipchains -A input -i $EXTERNAL_INTERFACE-s 96.0.0.0/4 -j DENY# 126 entspricht 01111110 - die Maske /3 wurde 127 beinhalten# daher mussen wir 112 - 126 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 112.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 113.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 114.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 115.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 116.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 117.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 118.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 119.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 120.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 121.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 122.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 123.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 124.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 125.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 126.0.0.0/8 -j DENY# 217-219 einzelnipchains -A input -i $EXTERNAL_INTERFACE-s 217.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 218.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 219.0.0.0/8 -j DENY# 220-223 -> /6ipchains -A input -i $EXTERNAL_INTERFACE-s 220.0.0.0/6 -j DENY# ICMP Typ 4 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE4 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 4 -d $ANYWHERE-j ACCEPT# ICMP Typ 12 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE12 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 12 -d $ANYWHERE-j ACCEPT# ICMP-Typ 3 f ur Providerrechner erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE3 -d $IPADDR -j ACCEPTB.1. DAS ERSTEFIREWALLSCRIPT 75ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 3 -d $MY_ISP -j ACCEPT# ICMP-Typ 3 Subtyp fragmentation-needed f ur alle freigebenipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR fragmentation-needed -d $ANYWHERE-j ACCEPT# ICMP-Typ 11 erlauben (ausgehend nur an unseren Provider)ipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE11 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 11 -d $MY_ISP -j ACCEPT# Ausgehendes Ping erlaubenipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 8 -d $ANYWHERE-j ACCEPTipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE0 -d $IPADDR -j ACCEPT# Ankommendes Ping nur f ur Provider erlaubenipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $MYISP 8 -d $IPADDR -j ACCEPTipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 0 -d $MYISP -j ACCEPT# Open Window Verbindungsaufbau sperrenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-s $IPADDR -d $ANYWHERE2000 -j REJECT# X11 Aufbau zu einem fremden Server verbietenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-s $IPADDR -d $ANYWHERE6000:6063 -j REJECT# X11 Aufbau von auen zu einem unserer Server verbietenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\-d $IPADDR 6000:6063 -j DENY -l# NFS (2049) uber UDP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p udp\-d $IPADDR 2049 -j DENY -l# NFS (2049) uber TCP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\-d $IPADDR 2049 -j DENY -lipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-d $ANYWHERE2049 -j DENY -l# DNS IP Adresse:NAMESERVER=xx.xx.xx.xx# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\76 ANHANG B. DIE BEISPIELSCRIPTS-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT#DNS Forwarding (Server zu Server)ipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53 \-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR 53 -j ACCEPT# DNS Zugriff fremder ClientsMYDNSCLIENTS=ww.xx.yy.zz/mmipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53\-d $MYDNSCLIENTS$UNPRIVPORTS-j ACCEPT# DNS Forwarding f ur fremde Clientsipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53 \-d $MYDNSCLIENTS53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS53 \-d $IPADDR 53 -j ACCEPT# DNS Zone-Transfer fremder ClientsMYDNSZONECLIENTS=ww.xx.yy.zz/mmipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $MYDNSZONECLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $MYDNSZONECLIENTS$UNPRIVPORTS-j ACCEPTB.1. DAS ERSTEFIREWALLSCRIPT 77# abgehende auth-Anfragenipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE113 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# ankommende auth-Anfragenipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 113 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 113 \-d $ANYWHERE$UNPRIVPORTS-j ACCEPT# oder statt der letzten zwei Befehle# ankommende auth-Anfragen ablehnen# ipchains -A input -i $EXTERNAL_INTERFACE-p tcp\# -s $ANYWHERE\# -d $IPADDR 113 -j REJECT78 ANHANG B. DIE BEISPIELSCRIPTSB.2 DasBastion Fir ewallscript# KonstantendefinitionEXTERNAL_INTERFACE=eth0 # Das Interface ins InternetIPADDR=123.45.67.89 # Adresse des InternetzugangsMY_ISP=123.45.67.90/16 # Der Bereich meines ProvidersBASTION_DMZ_INTERFACE=eth1 # internes InterfaceBASTION_DMZ_IPADDR=192.168.1.1 # Adresse dazuLOOPBACK_INTERFACE=lo # Local LoopbackLOOPBACK=127.0.0.0/8 # Loopback-AdressbereichCHOKE_DMZ_IPADDR=192.168.1.2 # ext. Interface der ChokeDMZ_ADDRESSES=192.168.1.0/24 # IP-Bereich der DMZDMZ_BROADCAST=192.168.1.255 # Broadcastadresse DMZANYWHERE=any/0 # Jede IP-AdresseCLASS_A=10.0.0.0/8 # Reservierter Bereich Klasse ACLASS_B=172.16.0.0/12 # Reservierter Bereich Klasse BCLASS_C=192.168.0.0/16 # Reservierter Bereich Klasse CCLASS_D=224.0.0.0/4 # Komplette Klasse DCLASS_E=240.0.0.0/5 # Komplette Klasse EBROADCAST_SRC=0.0.0.0 # Broadcast AbsenderBROADCAST_DEST=255.255.255.255 # Broadcast EmpfangerPRIVPORTS=0:1023 # Privilegierte PortnummernUNPRIVPORTS=1024:65535 # Unprivilegierte Portnummern# Alle bestehenden Regeln l oschenipchains -F# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECT# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdoecho 1 > $idone# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammenipchains -A input -i $EXTERNAL_INTERFACE\-s $IPADDR -j DENY -lipchains -A input -i $BASTION_DMZ_INTERFACE\-s $BASTION_DMZ_IPADDR-j DENY -lB.2. DAS BASTION FIREWALLSCRIPT 79# Reservierte A-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENY# Reservierte B-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENY# Reservierte C-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENY# Pakete mit Loopback als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENY# Pakete mit illegalen Broadcast Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $BROADCAST_DEST-j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $BROADCAST_SRC-j DENY# Pakete mit Klasse-D Adresse als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_D -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_D -j# Klasse-E Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_E -j DENY# Von der IANA reservierte Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s 1.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 2.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 5.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 7.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 23.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 27.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 31.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 37.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 39.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 41.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 42.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 58.0.0.0/7 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 60.0.0.0/8 -j DENY# 65 entspricht 01000001 - also wurde die Maske /3 leider die 64# mit ansprechen. Wir mussen daher 65-79 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 65.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 66.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 67.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 68.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 69.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 70.0.0.0/8 -j DENY80 ANHANG B. DIE BEISPIELSCRIPTSipchains -A input -i $EXTERNAL_INTERFACE-s 71.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 72.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 73.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 74.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 75.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 76.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 77.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 78.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 79.0.0.0/8 -j DENY# 80-95 l asst sich mit der Maske /4 ansprechenipchains -A input -i $EXTERNAL_INTERFACE-s 80.0.0.0/4 -j DENY# 96-111 l asst sich mit der Maske /4 ansprechenipchains -A input -i $EXTERNAL_INTERFACE-s 96.0.0.0/4 -j DENY# 126 entspricht 01111110 - die Maske /3 wurde 127 beinhalten# daher mussen wir 112 - 126 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 112.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 113.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 114.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 115.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 116.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 117.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 118.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 119.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 120.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 121.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 122.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 123.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 124.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 125.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 126.0.0.0/8 -j DENY# 217-219 einzelnipchains -A input -i $EXTERNAL_INTERFACE-s 217.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 218.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 219.0.0.0/8 -j DENY# 220-223 -> /6ipchains -A input -i $EXTERNAL_INTERFACE-s 220.0.0.0/6 -j DENY# ICMP Regeln nach auen# ICMP Typ 4 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE4 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 4 -d $ANYWHERE-j ACCEPT# ICMP Typ 12 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE12 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 12 -d $ANYWHERE-j ACCEPT# ICMP-Typ 3 f ur Providerrechner erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE3 -d $IPADDR -j ACCEPTB.2. DAS BASTION FIREWALLSCRIPT 81ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 3 -d $MY_ISP -j ACCEPT# ICMP-Typ 3 Subtyp fragmentation-needed f ur alle freigebenipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR fragmentation-needed -d $ANYWHERE-j ACCEPT# ICMP-Typ 11 erlauben (ausgehend nur an unseren Provider)ipchains -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE11 -d $IPADDR -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 11 -d $MY_ISP -j ACCEPT# Ausgehendes Ping erlaubenipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 8 -d $ANYWHERE-j ACCEPTipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE0 -d $IPADDR -j ACCEPT# Ankommendes Ping nur f ur Provider erlaubenipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $MYISP 8 -d $IPADDR -j ACCEPTipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 0 -d $MYISP -j ACCEPT# source-quench zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR4 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES4 -d $BASTION_DMZ_IPADDR-j ACCEPT# parameter-problem zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $ANYWHERE12 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES12 -d $ANYWHERE-j ACCEPT# destination-unreachable zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $ANYWHERE3 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES3 -d $ANYWHERE-j ACCEPT# time-exceeded zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR11 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES11 -d $BASTION_DMZ_IPADDR-j ACCEPT# Ausgehendes Ping aus der DMZipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES8 -d $ANYWHERE-j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\82 ANHANG B. DIE BEISPIELSCRIPTS-s $ANYWHERE0 -d $DMZ_ADDRESSES-j ACCEPT# Ankommendes Ping in die DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\-s $BASTION_DMZ_IPADDR8 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES0 -d $BASTION_DMZ_IPADDR-j ACCEPT# Open Window Verbindungsaufbau sperrenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-s $IPADDR -d $ANYWHERE2000 -j REJECT# X11 Aufbau zu einem fremden Server verbietenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-s $IPADDR -d $ANYWHERE6000:6063 -j REJECT# X11 Aufbau von auen zu einem unserer Server verbietenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\-d $IPADDR 6000:6063 -j DENY -l# NFS (2049) uber UDP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p udp\-d $IPADDR 2049 -j DENY -l# NFS (2049) uber TCP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\-d $IPADDR 2049 -j DENY -lipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-d $ANYWHERE2049 -j DENY -l# Der DNS-Server der Bastion akzeptiert Anfragen der Choke (UDP 53)ipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR53\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT# DNS Anfragen der Bastion an den Server der Choke (UDP/TCP 53)ipchains -A output -i $BASTION_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp\-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $CHOKE_DMZ_IPADDR53 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# DNS IP Adresse (Nameserver im Internet):B.2. DAS BASTION FIREWALLSCRIPT 83NAMESERVER=xx.xx.xx.xx#DNS Forwarding (Server zu Server)ipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53 \-d $NAMESERVER53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR 53 -j ACCEPT# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# DNS Zugriff fremder Clientsipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPT# abgehende auth-Anfragen ins Internetipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPTipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE113 \84 ANHANG B. DIE BEISPIELSCRIPTS-d $IPADDR $UNPRIVPORTS-j ACCEPT# ankommende auth-Anfragen aus dem Internetipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 113 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 113 \-d $ANYWHERE$UNPRIVPORTS-j ACCEPT# Bastion als auth-Client nach innenipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp \-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $DMZ_ADDRESSES113 -j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $DMZ_ADDRESSES113 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# Bastion als Server nach innenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR113 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $BASTION_DMZ_IPADDR113 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT# Mail uber SMTP# Zuerst der Name des Gateways# statt einem Provider kann hier auch "any/0" stehen, um die Bastion# selbst zum Mailserver zu ernennen.SMTP_GATEWAY=smtp.server.provider .beisp ielipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $SMTP_GATEWAY25 -j ACCEPTipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $SMTP_GATEWAY25 \-d $IPADDR $UNPRIVPORTS-j ACCEPT# Bastion nimmt SMTP Anfragen aus der DMZ entgegenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR25 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT# POP-Server der Bastion nimmt Pakete aus der DMZ entgegenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR110 -j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPTB.2. DAS BASTION FIREWALLSCRIPT 85# Bastion maskiert alle Pakete der Chokeipchains -A forward -i $EXTERNAL_INTERFACE\-s $CHOKE_DMZ_IPADDRESS-j MASQ86 ANHANG B. DIE BEISPIELSCRIPTSB.3 DasChoke Fir ewallscript#KonstantendefinitionCHOKE_DMZ_INTERFACE=eth0 # externes Interface der ChokeCHOKE_DMZ_IPADDR=192.168.1.2 # externe Adresse der ChokeCHOKE_LAN_INTERFACE=eth1 # internes Interface der ChokeCHOKE_LAN_IPADDR=192.168.5.1 # interne Adresse der ChokeLOOPBACK_INTERFACE=lo # Local LoopbackLOOPBACK=127.0.0.0/8 # Loopback-AdressbereichBASTION_DMZ_IPADDR=192.168.1.1 # interne Adresse der BastionDMZ_ADDRESSES=192.168.1.0/24 # IP-Bereich der DMZLAN_ADDRESSES=192.168.5.0/24 # IP-Bereich des LANDMZ_BROADCAST=192.168.1.255 # Broadcastadresse DMZANYWHERE=any/0 # Jede IP-AdresseCLASS_A=10.0.0.0/8 # Reservierter Bereich Klasse ACLASS_B=172.16.0.0/12 # Reservierter Bereich Klasse BCLASS_C=192.168.0.0/16 # Reservierter Bereich Klasse CCLASS_D=224.0.0.0/4 # Komplette Klasse DCLASS_E=240.0.0.0/5 # Komplette Klasse EBROADCAST_SRC=0.0.0.0 # Broadcast AbsenderBROADCAST_DEST=255.255.255.255 # Broadcast EmpfangerPRIVPORTS=0:1023 # Privilegierte PortnummernUNPRIVPORTS=1024:65535 # Unprivilegierte Portnummern# Alle bestehenden Regeln l oschenipchains -F# Voreingestellte Policies setzenipchains -P input REJECTipchains -P output REJECTipchains -P forward REJECT# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdoecho 1 > $idone# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammenipchains -A input -i $CHOKE_LAN_INTERFACE\-s $CHOKE_LAN_IPADDR-j REJECT -lipchains -A input -i CHOKE_DMZ_INTERFACE\-s $CHOKE_DMZ_IPADDR-j REJECT -l# Pakete mit privaten A-Klasse Adressen als Sender oder# Empfanger verwerfenB.3. DAS CHOKE FIREWALLSCRIPT 87ipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_A -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_A -j REJECT -lipchains -A output -i $CHOKE_DMZ_INTERFACE-d $CLASS_A -j REJECT -lipchains -A output -i $CHOKE_LAN_INTERFACE-d $CLASS_A -j REJECT -l# Pakete mit privaten B-Klasse Adressen als Sender oder# Empfanger verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_B -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_B -j REJECT -lipchains -A output -i $CHOKE_DMZ_INTERFACE-d $CLASS_B -j REJECT -lipchains -A output -i $CHOKE_LAN_INTERFACE-d $CLASS_B -j REJECT -l# Pakete mit D-Klasse Adressen als Sender verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_D -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_D -j REJECT -lipchains -A output -i $CHOKE_DMZ_INTERFACE-s $CLASS_D -j REJECT -lipchains -A output -i $CHOKE_LAN_INTERFACE-s $CLASS_D -j REJECT -l# Pakete mit E-Klasse Adressen verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $CLASS_E -j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $CLASS_E -j REJECT -l# Pakete mit Loopback Adressen als Sender verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE-s $LOOPBACK-j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE-s $LOOPBACK-j REJECT -l# Pakete mit fehlerhaften Broadcast Adressen verwerfenipchains -A input -i $CHOKE_DMZ_INTERFACE\-s $BROADCAST_DEST-j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE\-s $BROADCAST_DEST-j REJECT -lipchains -A input -i $CHOKE_DMZ_INTERFACE\-d $BROADCAST_SRC-j REJECT -lipchains -A input -i $CHOKE_LAN_INTERFACE\-d $BROADCAST_SRC-j REJECT -l# source-quench zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES4 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR4 -d $DMZ_ADDRESSES-j ACCEPT# parameter-problem zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $ANYWHERE12 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR12 -d $ANYWHERE-j ACCEPT# destination-unreachable zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $ANYWHERE3 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR3 -d $ANYWHERE-j ACCEPT# time-exceeded zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\88 ANHANG B. DIE BEISPIELSCRIPTS-s $BASTION_DMZ_IPADDR11 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR11 -d $BASTION_DMZ_IPADDR-j ACCEPT# Ausgehendes Ping ins Internetipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR8 -d $ANYWHERE-j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $ANYWHERE0 -d $CHOKE_DMZ_IPADDR-j ACCEPT# Ankommende Pings aus der DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\-s $DMZ_ADDRESSES8 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\-s $CHOKE_DMZ_IPADDR0 -d $DMZ_ADDRESSES-j ACCEPT# Der DNS-Server der Choke gibt Anfragen an die Bastion (UDP 53)ipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR53\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT# Der Nameserver der Choke l asst Anfragen aller Clients aus der# DMZ zu (TCP/UDP 53)ipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT# Choke als auth Serveripchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR113 -j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $CHOKE_DMZ_IPADDR113 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT# Choke als auth-Clientipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp\-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $ANYWHERE113 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# Choke erlaubt SMTP-Pakete an die BastionB.3. DAS CHOKE FIREWALLSCRIPT 89ipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp\-s CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $BASTION_DMZ_IPADDR25 \-d CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# POP3 Pakete an die Bastion werden weitergegeben:ipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp \-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR110 -j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT# Vollst andige Offnung der Kommunikation zwischen LAN und Chokeipchains -A input -i $CHOKE_LAN_INTERFACE\-s $LAN_ADDRESSES-j ACCEPTipchains -A output -i $CHOKE_LAN_INTERFACE\-d $LAN_ADDRESSES-j ACCEPT# Choke maskiert alle Pakete des LANipchains -A forward -i $CHOKE_DMZ_INTERFACE\-s $LAN_ADDRESSES-j MASQAnhang CProtokollbeschreibungenHier findenSiediewichtigstenProtokollbeschreibungenfur Diensteim Internet,mit derenHilfe eineFirewall beliebigaufgebautwerdenkann.DasFormatist immergleich,fur jedeZeile jederTabelleist eineipchainsRegelerforderlich.Die Beschreibungensindausfuhr-lich, nicht in jedemFall mussenalle Zeilenbeachtetwerden,aberfur alle Falle sind hierjeweilsdiegesammtenKommunikationswegedargestellt.Die AngabenderAdressenbeziehensichnaturlich zunachstauf einesimpleeinRechnerFirewall. Sollensiefur komplexereSituationendienen,somuanstellederAngabeADDRz.B. eineAdressangabefur einganzesNetzstehen.. .90C.1. DNS 91C.1 DNSBeschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsUDP Nameserver 53 output IPADDR 1024:65535 Antwort desfremdenServersUDP Nameserver 53 input IPADDR 1024:65535 Anfrageeineslo-kalenClientsTCP Nameserver 53 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP Nameserver 53 input IPADDR 1024:65535 ACKAnfragedesloka-len ServersUDP Nameserver 53 output IPADDR 53 oder an-dereAntwort desfremdenServersUDP Nameserver 53 input IPADDR 53 oder an-dereBitte um ZoneTransferTCP PrimarerNa-meserver53 output IPADDR 1024:65535 EgalAntwort auf BitteumZoneTransferTCP PrimarerNa-meserver53 input IPADDR 1024:65535 ACKAnfrage einesfremdenClientsUDP DNSClient 1024:65535 input IPADDR 53 Antwort desloka-len ServersUDP DNSClient 1024:65535 output IPADDR 53 Anfrage einesfremdenClientsTCP DNSClient 1024:65535 input IPADDR 53 EgalAntwort desloka-len ServersTCP DNSClient 1024:65535 output IPADDR 53 ACKAnfrage einesfremdenServersUDP DNSServer 53 oder an-dereinput IPADDR 53 Antwort desloka-len ServersUDP DNSServer 53 oder an-dereoutput IPADDR 53 Jemandbittet umZoneTransferTCP SekundarerNameserver1024:65535 input IPADDR 53 EgalAntwort auf BitteumZoneTransferTCP SekundarerNameserver1024:65535 output IPADDR 53 ACKTabelleC.1:DasDNSProtokoll92 ANHANG C. PROTOKOLLBESCHREIBUNGENC.2 identd oder authBeschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrage von lo-kalemClientTCP ANYWHERE 113 output IPADDR 1024:65535 EgalAntwort vonfremdemServerTCP ANYWHERE 113 input IPADDR 1024:65535 ACKAnfrage vonfremdemClientTCP ANYWHERE 1024:65535 input IPADDR 113 EgalAntwort von lo-kalemServerTCP ANYWHERE 1024:65535 output IPADDR 113 ACKTabelleC.2:DasidentdProtokollC.3 UsenetNews(NNTP)Beschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP News Server 119 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP News Server 119 input IPADDR 1024:65535 ACKAnfrage einesfremdenClientsTCP NNTPClient 1024:65535 input IPADDR 119 EgalAntwort desloka-len ServersTCP NNTPClient 1024:65535 output IPADDR 119 ACKAnfragedesloka-len ServersTCP Newsfeed 119 output IPADDR 1024:65535:EgalAntwort desfremdenServersTCP Newsfeed 119 input IPADDR 1024:65535:ACKTabelleC.3:DasNNTPProtokollC.4. E-MAIL (SMTP/POP/IMAP) 93C.4 E-Mail (SMTP/POP/IMAP)Beschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAbgehendeMailsendenTCP ANYWHERE 25 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP ANYWHERE 25 input IPADDR 1024:65535 ACKAnkommendeMail empfangenTCP ANYWHERE 1024:65535 input IPADDR 25 EgalAntwort desloka-len ServersTCP ANYWHERE 1024:65535 output IPADDR 25 ACKPOP Anfrage ei-nes lokalen Cli-entsTCP POPServer 110 output IPADDR 1024:65535 EgalAntwort desfremden POPServersTCP POPServer 110 input IPADDR 1024:65535 ACKAnfrage einesfremden POPClientsTCP POPClient 1024:65535 input IPADDR 110 EgalAntwort desloka-len POPServersTCP POPClient 1024:65535 output IPADDR 110 ACKIMAP Anfrageeines lokalenClientsTCP IMAP Server 143 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP IMAP Server 143 input IPADDR 1024:65535 ACKAnfrage einesfremden IMAPClientsTCP IMAP Client 1024:65535 input IPADDR 143 EgalAntwort desloka-len ServersTCP IMAP Client 1024:65535 output IPADDR 143 ACKTabelleC.4:Die E-Mail Protokolle94 ANHANG C. PROTOKOLLBESCHREIBUNGENC.5 TelnetBeschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP ANYWHERE 23 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP ANYWHERE 23 input IPADDR 1024:65535 ACKAnfrage einesfremdenClientsTCP TelnetClient 1024:65535 input IPADDR 23 EgalAntwort desloka-len ServersTCP TelnetClient 1024:65535 output IPADDR 23 ACKTabelleC.5:DasTelnetProtokollC.6 Secure Shell (SSH)Beschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP ANYWHERE 22 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP ANYWHERE 22 input IPADDR 1024:65535 ACKAnfrageeineslo-kalenClientsTCP ANYWHERE 22 output IPADDR 513:1023 EgalAntwort desfremdenServersTCP ANYWHERE 22 input IPADDR 513:1023 ACKAnfrage einesfremdenClientsTCP sshClients 1024:65535 input IPADDR 22 EgalAntwort desloka-len ServersTCP sshClients 1024:65535 output IPADDR 22 ACKAnfrage einesfremdenClientsTCP sshClients 513:1023 input IPADDR 22 EgalAntwort desloka-len ServersTCP sshClients 513:1023 output IPADDR 22 ACKTabelleC.6:DasSSHProtokollC.7. FTP 95C.7 FTPBeschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP ANYWHERE 21 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP ANYWHERE 21 input IPADDR 1024:65535 ACKDatenkanal Auf-bau vom frem-den Server, akti-verModusTCP ANYWHERE 20 input IPADDR 1024:65535 EgalAntwort auf Ka-nalaufbau durchlokalen Client,akt.ModusTCP ANYWHERE 20 output IPADDR 1024:65535 ACKDatenkanal Auf-bau zum frem-denServer, passi-verModusTCP ANYWHERE 1024:65535 output IPADDR 1024:65535 EgalAntwort auf Ka-nalaufbau durchfremden Server,passiver ModusTCP ANYWHERE 1024:65535 input IPADDR 1024:65535 ACKAnfrage einesfremdenClientsTCP ANYWHERE 1024:65535 input IPADDR 21 EgalAntwort desloka-len ServersTCP ANYWHERE 1024:65535 output IPADDR 21 ACKDatenkanal Auf-bauvomlok. Ser-ver, aktiver Mo-dusTCP ANYWHERE 1024:65535 output IPADDR 20 EgalAntwort auf Ka-nalaufbau durchfremden Client,akt.ModusTCP ANYWHERE 1024:65535 input IPADDR 20 ACKDatenkanal Auf-bauzumlok. Ser-ver, passiver Mo-dusTCP ANYWHERE 1024:65535 input IPADDR 1024:65535 EgalAntwort auf Ka-nalaufbau durchlok. Server, passi-verModusTCP ANYWHERE 1024:65535 output IPADDR 1024:65535 ACKTabelleC.7:DasFTPProtokoll96 ANHANG C. PROTOKOLLBESCHREIBUNGENC.8 HTTP - NormalBeschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP ANYWHERE 80 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP ANYWHERE 80 input IPADDR 1024:65535 ACKAnfrage einesfremdenClientsTCP ANYWHERE 1024:65535 input IPADDR 80 EgalAntwort desloka-len ServersTCP ANYWHERE 1024:65535 output IPADDR 80 ACKTabelleC.8:DasHTTPProtokollC.9 HTTP - mit Secure Socket Layer (SSL)Beschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP ANYWHERE 443 output IPADDR 1024:65535 EgalAntwort desfremdenServersTCP ANYWHERE 443 input IPADDR 1024:65535 ACKAnfrage einesfremdenClientsTCP ANYWHERE 1024:65535 input IPADDR 443 EgalAntwort desloka-len ServersTCP ANYWHERE 1024:65535 output IPADDR 443 ACKTabelleC.9:DasHTTP/SSLProtokollC.10 HTTP-Pr oxy ZugriffBeschreibung Proto-kollRemoteIP RemotePort Chain Local IP Local Port TCPFlagsAnfrageeineslo-kalenClientsTCP ProxyServer ProxyPort output IPADDR 1024:65535 EgalAntwort desProxyServersTCP ProxyServer ProxyPort input IPADDR 1024:65535 ACKTabelleC.10:DasWebProxyProtokollVorwortGrundlagenDas OSI ReferenzmodellDie BitbertragungsschichtDie SicherungsschichtDie VermittlungsschichtDie TransportschichtDie SitzungsschichtDie DarstellungsschichtDie AnwendungsschichtDas TCP/IP ReferenzmodellDie VermittlungsschichtDie TransportschichtKommunikationsablauf einer TCP--VerbindungGrundlagen der FirewalltechnikDie Voreinstellung fr PaketfilterREJECT oder DENYZusammenfassungFiltern von eingehenden PaketenFiltern nach IP--AdressenFiltern nach Absender--AdressenFiltern nach Empfnger--AdressenFiltern nach PortnummernFiltern nach der Absender--PortnummerFiltern nach der Empfnger--PortnummerFiltern nach TCP--Status--FlagsAngriffsformen von auerhalbPortscansDenial--of--Service--Attacks Filtern von ausgehenden PaketenFiltern nach IP--AdressenFiltern nach Absender--AdresseFiltern nach Empfnger--AdresseFiltern nach PortnummernFiltern nach TCP--Status--FlagsGestaltung einer Firewall mit LinuxDie drei Standard--KettenDas Handwerkszeug: ipchainsFormat der AngabenIP--AdressenPortsPraktischer Aufbau einer FirewallGrundeinstellungenEin paar Techniken zur Abwehr von geflschten PaketenAusfiltern offensichtlich falscher AdressenICMP--Nachrichten filternDienste auf unprivilegierten PortsWichtige Dienste erlaubenDie Firewall als Router ins InternetRouter oder ProxyDie Proxy--TechnikDie Router--TechnikDas Problem der reservierten AdressenMasquerading als ProblemlsungVerschiedene Modelle von routenden FirewallsDie Bastion--Host--FirewallDie Demilitarisierte Zone (DMZ)Exemplarischer Aufbau einer DMZ--FirewallDie symbolischen KonstantenDie Konstanten fr die BastionDie Konstanten fr die ChokeWeitere GrundeinstellungenICMP--Nachrichten filternSource--Quench NachrichtenParameter--Problem NachrichtenDestination--Unreachable NachrichtenTime--Exceeded NachrichtenPing KonfigurationDienste auf unprivilegierten PortsDomain Name ServiceNutzung eines ffentlichen NameserversBetreiben eigener NameserverDer ident--Service (auth)Konfiguration der BastionKonfiguration der ChokeE--MailAbgehende Mails ber die Bastion verschickenMailempfang ber POP--Server auf der BastionAlle weiteren DiensteLAN Zugriff auf die ChokeUnd schlielich das MasqueradingWichtige PortnummernHufig gescannte PortsICMP Nachrichten TypenDie Beispiel--ScriptsDas erste FirewallscriptDas Bastion FirewallscriptDas Choke FirewallscriptProtokollbeschreibungenDNSidentd oder authUsenet News (NNTP)E-Mail (SMTP/POP/IMAP)TelnetSecure Shell (SSH)FTPHTTP - NormalHTTP - mit Secure Socket Layer (SSL)HTTP-Proxy Zugriff

Recommended

View more >