Firewallaufbau mit Linux - Linux-Praxis · PDF fileKapitel 1 Vorwort Die vorliegende Dokumentation beschreibt Funktionsweise, Aufbau und Wartung eines Firewallrechners unter Linux

CrashkursFirewallaufbauunterLinux

FlorianKalhammer

21.Marz2001

Inhaltsverzeichnis

1 Vorwort 5

2 Grundlagen 62.1 DasOSI Referenzmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.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. . . . . . . . . . . . . . . . . . . . . . . 9

2.2 DasTCP/IPReferenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Die Vermittlungsschicht . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Die Transportschicht. . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 KommunikationsablaufeinerTCP–Verbindung . . . . . . . . . . . . . . . 15

3 Grundlagen der Fir ewalltechnik 183.1 Die Voreinstellungfur Paketfilter . . . . . . . . . . . . . . . . . . . . . . . 203.2 REJECToderDENY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Filter n von eingehendenPaketen 244.1 Filtern nachIP–Adressen. . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 FilternnachAbsender–Adressen. . . . . . . . . . . . . . . . . . . 244.1.2 FilternnachEmpfanger–Adressen. . . . . . . . . . . . . . . . . . 25

4.2 Filtern nachPortnummern . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.1 FilternnachderAbsender–Portnummer. . . . . . . . . . . . . . . 254.2.2 FilternnachderEmpfanger–Portnummer . . . . . . . . . . . . . . 26

4.3 Filtern nachTCP–Status–Flags. . . . . . . . . . . . . . . . . . . . . . . . 264.4 Angriffsformenvon außerhalb . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4.1 Portscans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.2 Denial–of–Service–Attacks. . . . . . . . . . . . . . . . . . . . . 27

5 Filter n von ausgehendenPaketen 295.1 Filtern nachIP–Adressen. . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 FilternnachAbsender–Adresse . . . . . . . . . . . . . . . . . . . 295.1.2 FilternnachEmpfanger–Adresse. . . . . . . . . . . . . . . . . . . 29

5.2 Filtern nachPortnummern . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Filtern nachTCP–Status–Flags. . . . . . . . . . . . . . . . . . . . . . . . 30

6 Gestaltungeiner Fir ewall mit Linux 316.1 Die drei Standard–Ketten . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.2 DasHandwerkszeug:ipchains . . . . . . . . . . . . . . . . . . . . . . . . 326.3 FormatderAngaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.3.1 IP–Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2

INHALTSVERZEICHNIS 3

6.3.2 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.4 PraktischerAufbaueinerFirewall . . . . . . . . . . . . . . . . . . . . . . 34

6.4.1 Grundeinstellungen. . . . . . . . . . . . . . . . . . . . . . . . . . 346.4.2 Ein paarTechnikenzur Abwehrvon gefalschtenPaketen . . . . . . 356.4.3 AusfilternoffensichtlichfalscherAdressen . . . . . . . . . . . . . 366.4.4 ICMP–Nachrichtenfiltern . . . . . . . . . . . . . . . . . . . . . . 396.4.5 DiensteaufunprivilegiertenPorts . . . . . . . . . . . . . . . . . . 416.4.6 WichtigeDiensteerlauben . . . . . . . . . . . . . . . . . . . . . . 42

7 Die Fir ewall alsRouter ins Inter net 467.1 RouteroderProxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.1.1 Die Proxy–Technik . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.2 Die Router–Technik . . . . . . . . . . . . . . . . . . . . . . . . . 47

7.2 DasProblemderreserviertenAdressen. . . . . . . . . . . . . . . . . . . . 487.3 MasqueradingalsProblemlosung. . . . . . . . . . . . . . . . . . . . . . . 497.4 VerschiedeneModellevon routendenFirewalls . . . . . . . . . . . . . . . 50

7.4.1 Die Bastion–Host–Firewall . . . . . . . . . . . . . . . . . . . . . . 507.4.2 Die DemilitarisierteZone(DMZ) . . . . . . . . . . . . . . . . . . 51

8 ExemplarischerAufbau einer DMZ–Fir ewall 538.1 Die symbolischenKonstanten . . . . . . . . . . . . . . . . . . . . . . . . 54

8.1.1 Die Konstantenfur die Bastion. . . . . . . . . . . . . . . . . . . . 548.1.2 Die Konstantenfur die Choke . . . . . . . . . . . . . . . . . . . . 55

8.2 WeitereGrundeinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . 558.3 ICMP–Nachrichtenfiltern . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.3.1 Source–QuenchNachrichten. . . . . . . . . . . . . . . . . . . . . 588.3.2 Parameter–ProblemNachrichten. . . . . . . . . . . . . . . . . . . 598.3.3 Destination–UnreachableNachrichten. . . . . . . . . . . . . . . . 598.3.4 Time–ExceededNachrichten. . . . . . . . . . . . . . . . . . . . . 598.3.5 PingKonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 60

8.4 Diensteauf unprivilegiertenPorts . . . . . . . . . . . . . . . . . . . . . . 618.5 DomainNameService . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

8.5.1 NutzungeinesoffentlichenNameservers . . . . . . . . . . . . . . 618.5.2 BetreibeneigenerNameserver . . . . . . . . . . . . . . . . . . . . 62

8.6 Der ident–Service(auth) . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.6.1 KonfigurationderBastion . . . . . . . . . . . . . . . . . . . . . . 648.6.2 KonfigurationderChoke . . . . . . . . . . . . . . . . . . . . . . . 65

8.7 E–Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658.7.1 AbgehendeMails uberdieBastionverschicken . . . . . . . . . . . 658.7.2 MailempfanguberPOP–ServeraufderBastion . . . . . . . . . . . 66

8.8 Alle weiterenDienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678.9 LAN Zugriff auf dieChoke . . . . . . . . . . . . . . . . . . . . . . . . . . 678.10 Und schließlichdasMasquerading. . . . . . . . . . . . . . . . . . . . . . 68

A Wichtige Portnummern 69A.1 HaufiggescanntePorts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A.2 ICMP NachrichtenTypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

B Die Beispiel–Scripts 72B.1 DasersteFirewallscript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72B.2 DasBastionFirewallscript . . . . . . . . . . . . . . . . . . . . . . . . . . 78B.3 DasChokeFirewallscript . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4 INHALTSVERZEICHNIS

C 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Kapitel 1

Vorwort

Die vorliegendeDokumentationbeschreibtFunktionsweise,Aufbau und WartungeinesFirewallrechnersunterLinux. Sie ist alsbegleitendesMaterial fur eineSchulunggedacht,nicht als Selbststudium–Hilfe.DasThemaFirewall ist ein weit gefacherterBereich,derhier nicht abschließendbehandeltwerdenkann,es sollen die in der Schulungund demAufbauvorkommendenPunktebesprochenunddargestelltwerden.

EineFirewall ist ein Sicherheitssystem,das– wie alle anderenSicherheitssystemeauch–im 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 einLinux–Systemmit 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 wesentlichen–auchnureinsyntaktischer, die Regelnbleibengroßtenteilsdieselben.

DieseDokumentationkanneinesnicht sein,eineEinfuhrungin bzw. ein Lehrgangfur Li-nux selbst.Eswerdenhier alsowederdie Installation,nochdie grundlegendenTechnikendesUmgangsmit Linux beschrieben.Eine Stand–alone–Firewall mit Linux bedarfaller-dingsauchnicht einergroßenVerwaltungsarbeit,sodaßein durchschnittlichesWissenumLinux sicherausreichendist, um die hier beschriebenenVorgangenachzuvollziehenundreproduzierenzu konnen.Wo immer esnotwendigist, genaueAngabenzu machen,wobzw. wie etwasin Linux einzustellenist, wird esausreichendbeschrieben.

Daim vorliegendenFall dieLinux–DistributionderS.u.S.EGmbHeingesetztwird (S.u.S.E7.0 Professional),bezieheich mich im wesentlichenauchauf die in dieserDistributionublichenDateienundVerzeichnisse.Im GroßenundGanzensolltenaberalle Techniken–mit kleinenAnderungen– auchin jederanderenmodernenLinux–Distribution implemen-tierbarsein.Die Unterschiedewerdensichim Wesentlichenauf verschiedeneStartdateienreduzieren,in denendieentsprechendenFirewall–Regelneingetragenwerden.DieseStart-dateiensind in fastjederDistribution unterschiedlich,daherwurdeeineallgemeingultigeBeschreibungdenRahmendieserDokumentationsichersprengen.

5

Kapitel 2

Grundlagen

Der Begriff Firewall hatkeineeindeutigeDefinition undkeinestandardisierteBedeutung.EshandeltsichvielmehrumeinModell zurAbsicherungeinesComputernetzesgegenuberanderen– meistoffentlichen– Netzen.Im RahmendieserAnforderungkommen– je nachGroßeundKonzeptdeszuschutzendenNetzes– verschiedeneLosungsansatzein Frage.InjedemFall mußdiegewunschteSicherheitin verschiedenenSchichtenangegangenwerden,eineinzigerMechanismus,wie etwanur einePaket–Firewall 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:

� WelcheInternet–DienstedurfenvomlokalenNetzausgenutztwerden?� WelcheDienstedarfdieganzeWelt in Anspruchnehmen?� WelcheDienstedurfenausgewahlteBenutzeroderComputerin Anspruchnehmen?� WelcheDienstedurfennur lokal genutztwerden?

DergrundlegendeAnsatzzurImplementierungdieserStrategienistdiesogenanntePaketfilter–Firewall. Im weiterenVerlaufdieserDarstellungwird esalsohauptsachlichum die Kon-zeptionund Wartungeiner solchenPaketfilter–Firewall gehen,implementiertmit einemLinux–System.Linux bietet fur dieseAufgabealle notwendigenWerkzeugebereitsimBetriebssystem–Kern,es ist alsonicht notwendig,komplizierteZusatzinstallationenvor-zunehmen,dieeinSystemnur instabilerwerdenlassen.

Auf deranderenSeitewurdeja schonerwahnt,daßeinehinreichendeSicherheitnur uberverschiedene,aufeinanderaufbauendeMechanismenherzustellenist.Auchfurdiesehoher-gelegenenSicherheitsstufensindunterLinux alleWerkzeugebereitsin derStandard–Installationvorhanden.Zunachstgilt unserAugenmerkjedochdenMechanismendesPaketfilterns.UmgrundsatzlichdiesenVorgangverstehenzukonnen,ist esnotwendigeinpaargrundlegendeBegriffe undTechnikenderComputervernetzungzu beschreiben.Wasist uberhauptKom-munikationin Netzwerken,wie lauft sieabundwelcheMittel desEingreifensstehenunsalsozurVerfugung?

2.1 DasOSI Referenzmodell

EndedersiebzigerJahrewurdeein theoretischesReferenzmodellfur die VernetzungvonComputernentworfen,dasauchheutenochvielen Darstellungenzugrundeliegt. Es han-

6

2.1. DAS OSIREFERENZMODELL 7

delt sich dabeium dassogenannteOSI–Referenzmodell.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-Referenzmodell

Die beidenunterstenSchichtensind– im FalleeinerherkommlichenNetzverbindungetwauber Ethernet–Karten– auf der Netzwerkkarteselbstimplementiert.Sie sind also nichtBestandteilderSoftwareoderdesBetriebssystems.

Von untennachobenbetrachtetkommendenverschiedenenSchichtendie folgendenAuf-gabenzu:

2.1.1 Die Bit ubertragungsschicht

Die Bitubertragungsschicht(physicalLayer)ist verantwortlich fur dieUbertragungderein-zelnenBits,siehatalsoeinfachdieAufgabedafur zusorgen,daßwo 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 Sicherungsschicht

Die Sicherungsschicht(datalink layer) verarbeitetdie ubertragenenRohdatenindemsieeineDatenreihedarauserstellt und dieseDatenreihegewohnlichermaßenin einensoge-nanntenDatenubertragungsrahmen(dataframe)packt.Die Sicherungsschichtkommuni-ziert mit ihrer gegenuberliegendenSicherungsschichtdurchsogenannteQuittungsrahmen,diekorrektverarbeitetwerdenmussen.

8 KAPITEL 2. GRUNDLAGEN

Um dasGanzeeinmal im Detail zu sehenfolgt hier die Darstellungder FramestruktureinesDatenrahmens(engl.frame)derIEEE802.3Norm,alsoderNorm,dieunserEthernetbenutzt:

Präambel Zieladresse Quelladresse Da− −ten Pad

DatenfeldesdesBeginn des

Rahmen−begrenzers

Bytes 7 1 6 6 2 0−1500 0−46 4

Laenge Pruefsumme

Bild 2.2: Das802.3Frameformat

Die beidenAdressfelderenthaltendabeidie Hardwareadresse(MAC–Adresse)der jewei-ligen Netzwerkkarten.DasDatenfeldenthalt die eigentlichenDaten,falls eswenigerals46 Byte sind, so wird dasPad–Feldbenutztum die (physikalischnotwendigen)46 Byteaufzufullen.Die Prufsummeist schließlicheineMoglichkeit, Fehlerbei derUbermittlungdirekt zu erkennenundein fehlerhaftesPaketgegebenenfallsnochmalanzufordern.

2.1.3 Die Vermittlungsschicht

DieseSchicht(Network Layer)steuertdieverschiedenenTransportwegeinnerhalbdesNet-zes.In kleinenLAN ist dieseSchichtalsoverhaltnismaßigdunn, in großenNetzen(z.B.demInternet)hatsiesehrumfangreicheAufgaben.Die WahlderverschiedenenmoglichenRoutenvomSenderzumEmpfanger, dasoptimaleAusnutzenderbestehendenVerbindun-genundahnlichessindihre Aufgaben.

2.1.4 Die Transportschicht

Die Aufgabeder Transportschicht(TransportLayer) ist es,denDatenstromvon der Sit-zungsschichtzurVermittlungsschichtweiterzugeben,eventuellin kleinerePaketezupackenund dafur zu sorgen,daßalle Teile in der korrektenReihenfolgeankommen.Die Trans-portschichtbauteinedirekteKommunikationzwischenSenderund Empfangerauf, undarbeitetmit einementsprechendendirektenProtokoll. Man sprichthier von einerEnde-zu-EndeSchicht,im GegensatzdazuwarendiebisherbesprochenenSchichtensogenanntegeketteteSchichten.Dasheißt,daßsienichtunbedingteinedirekteKommunikationmit derZielmaschinebetrieben,sondernnur mit denzwischenSenderund EmpfangerliegendenZwischenstationen(Gateways,Bridges,...)

Viele Computerarbeitenheuteim Multitasking-Betrieb,eskannalsosein,daßzwischenzwei RechnernmehrereunabhangigeNetzwerkverbindungenbestehen.Auch die Koordi-nationdieserTatsacheist AufgabederTransportschicht.

2.1.5 Die Sitzungsschicht

Die Sitzungsschicht(SessionLayer) hat ahnlicheAufgabenwie die Transportschicht,je-dochin eineretwasgehobenerenForm. SiemußzumBeispielabgebrocheneTransferver-suchean der Stellewiederaufnehmen,an der sie abgebrochenwurden.Insgesamtkonntemanesdamitzusammenfassen,daßdieSitzungsschichtzustandigfur dieDialogsteuerungist.

2.2. DAS TCP/IPREFERENZMODELL 9

2.1.6 Die Darstellungsschicht

Die Darstellungsschicht(PresentationLayer)ist zustandigfur diekorrekteDarstellungderDaten.DieseSchichtwird z.B. dadurchnotwendig,daßverschiedeneComputerverschie-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 Anwendungsschicht

Die letzteSchichtdesOSI-Modells(ApplicationLayer)enthalt nundieverschiedenenAn-wendungen,diesichgegenseitiguberdasNetzverstandigen.DieseSchichtist in derRegeldirekt in dasAnwenderprogrammprogrammiertundenthalt die jeweiligenProtokolle, mitdenendieProgrammekommunizieren.

2.2 DasTCP/IP Referenzmodell

NachdemdasOSI-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:

Netzzugriffsschicht

Internet−Schicht

Transportschicht

Anwendungsschicht

Bild 2.3: DasTCP/IP-Schichtenmodell

Diesevier Schichtenkommunizierennicht genaumit denendesOSI–Modells,vereinfachtkann man sagen,daßdie Netzzugriffsschichtdie beidenunterstenSchichtendesOSI–Modellsenthalten,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:


802.3, PPP, SLIP, ...

IP

UDPTCP

FTP HTTP SMTP TELNET ...

ICMP

Anwendung

Transport

Vermittlung

Netzzugriff

Bild 2.4: Protokolle desTCP/IP-Schichtenmodells

In derAnwendungsschichtarbeitenalsosehrviele verschiedeneProtokolle, in derTrans-portschichtgeradenochzwei, in derVermittlungsschichtnur einesundauchauf derNetz-zugriffsschichteines(allerdingseinesausvielenmoglichen).

JedeSchichtdiesesModells mußInformationenbesitzen,an welcheAbteilung der uberihr liegendenSchichtsiedenDatenstrombeimEmpfangweitergebensoll. Von untennachobenbetrachtetergibt sichdamitfolgenderVorgang:

� Die Netzzugriffsschichtbekommtein PaketausdemNetz.Siehatkein ProblemmitderWeitergabe,denndie uberihr liegendeSchichtenthalt nurein Protokoll, IP.

� DasInternet–Protokoll (IP) derVermittlungsschichtmußaufgrundder ihr ubermit-teltenInformationschonentscheiden,wem siedasPaket weitergibt. EsstehenhierdreiMoglichkeitenzurAuswahl:

– DasPaketbleibt in derVermittlingsschichtundwird vomInternetControlMes-sageProtocol(ICMP) weiterverarbeitet(z.B.ping)

– DasPaket Gehort zu einemTCP–Datenstromund muß an dasTransmissionControlProtocol(TCP)derTransportschichtweitergeleitetwerden.

– DasPaket enthalt ein UDP-Datagramund mußdaheran dasUserDatagramProtocol(UDP)derTransportschichtweitergegebenwerden.

DieseInformation muß IP ausdem IP–Datagram–Headergewinnen. Das FormatdiesesHeadersist weiteruntenerklart.

� Die ProtokollederTransportschicht(TCPundUDP)habendiegroßteAufgabe,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.1 Die Vermittlungsschicht

Auf der Vermittlungsschicht(Internet–Schicht)von TCP/IParbeitetim Wesentlichennurein Protokoll, dasIP (InternetProtocol).DiesesProtokoll arbeitetnicht mit den physi-kalischenAdressenvon Netzwerkkarten,sondernmit logischenAdressen,ebendenall-seitsbekanntenIP–Adressen.DieseSchichtfugt deneigentlichzu ubermittelndenDatennochVerwaltungsinformationenhinzu.DiesesFormatwird alsDatagram–Formatbezeich-netundhatdie folgendeStruktur:

0 4 8 12 16 20 24 28 31Bits

Flags Fragment−Offset

Version IHL Diensttyp Gesamtlaenge

Kennung

Lebensdauer Protokoll Kopf−Pruefsumme

Sender IP Adresse

Optionen Fuellzeichen

Empfaenger IP Adresse

Ab hier kommen die Daten...

Hea

der

Bild 2.5: DasIP–DatagramFormat

Die BedeutungdereinzelnenFelderist

Version Ein vier Bit breitesFeld,daßdieVersionsnummervon 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 sichsoeinemaximaleGroßevon Datagrammenvon 65535Byte. DieserWert liegt weit uber dem maximalenWert der einzelnenNetzsysteme,daherreichen16Bit aus.

Kennung JedesIP-DatagrammmußeineeigeneKennunghaben,um beimWiederzusam-menbaurichtig eingeordnetzu werden.

Flags Ein Drei–Bit–FelddasFlagszur SteuerungderFragmentierungenthalt.

Lebensdauer In Netzenwie demInternet,in denenvieleDatagrammeaufunterschiedlch-stenWegenversuchenzumZiel zukommen,mußeinemaximaleLebensdauerhaben,sonstwerdensieunendlichoft geroutet.DiesesFeldenthalt eineZahl,dievom Sen-dereingetragenwurde.JederGatewaymußdieseZahlumeinsherunterzahlen,wennereinDatagrammroutet.Ist derWertNull, sodarfkeinRouterdasDatagrammmehrweiterleiten.UblicheStartwertesind32 oder4 (nur lokaleNetzesetzensoniedrigeLebensdaueran)


Protokoll 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 – ICMP

Kopf–Prufsumme PrufsummeuberdenInhalt desHeaders,nicht der Daten.Die Uber-prufungderDatenwird von derTransportschichterledigt.

SenderIP–Adr esse32Bit IP-AdressedesSenders

Empfanger IP–Adr esse32 Bit IP-AdressedesEmpfangers

Optionen 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., daßdiesesProtokoll in der Lage ist, Paketezuschicken,die nicht anein Transportprotokoll derTransportschichtgebundensind,sondernebennurvon Vermittlungsschichtzu Vermittlungsschichtgehen.

Die Aufgaben,diediesesProtokoll zuerfullenhatsindhier kurz aufgelistet:

Flußkontrolle Wennein RechnerDatagrammesoschnellschickt,daßderEmpfangersienicht rechtzeitigverarbeitenkann,so schicktder EmpfangeruberICMP eineMel-dungan denSender, daßdie Sendungenvorubergehendstoppensollen.NachdemderEmpfangeralle anstehendenDatagrammeverarbeitethat,schickter erneuteineMeldung,daßer wiederempfangsbereitist.

Erk ennenvon unerreichbarenZielr echnern WenneinGatewayerkennt,daßeinbestimm-ter Rechnernicht erreichbarist, soschickter andenAbsenderdesPaketeseineDe-stinationunreachableMeldunguberICMP

Routenoptimierung WenneinGatewayerkennt,daßereinenUmweg 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. Dasping–KommandonutztdieseEcho-Meldung.

2.2.2 Die Transportschicht

Auf der Transportschichtvon TCP/IP arbeitenzwei verschiedeneProtokolle, TCP undUDP. DerwesentlicheUnterschiedzwischendenbeidenProtokollenist dieFragederKom-munikationssteuerung.TCP (TransmissionControl Protocol)arbeitetverbindungsorien-tiert, esbautalsoeinenDatenstromzwischenEmpfangerundSenderauf,derubermehrerePaketeverteilt ist und dessenkorrekterEmpfangpermanentdurchQuittungspaketevom


Empfangerbestatigtwerdenmuß.Im GegensatzdazuarbeitetUDP(UserDatagramProto-col) verbindungslos, dasheißt,eswerdeneinfachPakete(Datagramme)vom SenderzumEmpfangergeschickt,ohnedaßdieserdenEmpfangquittierenmuß.

BeideProtokolle arbeitenwiedermit einemsogenanntenHeader, derdemeigentlichenDa-tenpaketvorangestelltwird. BeidenHeaderformenist einsgemeinsam,sieenthalteneinenEintragfur die PortnummerdesSenderprozessesunddie desEmpfangerprozesses.DiesePortnummernwerdenunsim nachstenAbschnittnochgenauerbeschaftigen.Im folgendenwerdenbeideHeaderformatekurz dargestellt:

DasUDP–MessageFormat

Die interneStrukturdesUDP–Headersist sehreinfach.Als datagramorientiertes(verbin-dungsloses)Protokoll benotigt UDP keinerleiInformationenuberSequenznummernoderahnliches,derbenotigteHeaderist alsosehrklein:

Quell−Portnummer Ziel−Portnummer

Laenge

Ab hier Daten

Bits

0 16 31

Pruefsumme

Bild 2.6: DasUDP–MessageFormat


Quellportnummer bezeichnetdiePortnummerdesAnwenderschichtprogrammes,vondemdieUDP-Messageabgeschicktwurde.

Zielportnummer bezeichnetdie PortnummerdesEmpfangerprogrammsauf derAnwen-dungsschicht.

Lange Hier stehtdieLangedergesamtenUDP-Message(incl. Header)

Prufsumme EinePrufsummeuberdasDatenfeld

UDP wird uberalldort verwendet,wo entwederdie Datenmengeso klein ist, daßessichnicht lohnenwurde,einengroßenHeaderzu benutzen,weil der großerals 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 Fragemußnochmalgestelltwerden.

DasTCP–SegmentFormat

TCPist im GegensatzzuUDPeinverbindungsorientiertesProtokoll, dasDatenstromever-arbeitet,die von der Anwendungsschichtkommen.TCP garantiertdie VersendungvonDatendurcheingebauteHandshake-Mechanismen.


TCP bieteteinenverlasslichenDatentransferdurchdie VerwendungeinesMechanismus,derDatenpakete(sogenannteSegmente)aneinenEmpfangerschicktundauf eineBestati-gungdesEmpfangsseitensdesEmpfangerswartet.Dabeiuberpruft der EmpfangerauchwiedermittelseinerPrufsumme,obdasPaket fehlerfreiangekommenist.

DasFormatdesHeadersist zwangslaufigalsowesentlichkomplexeralsdasvon UDP:

0 4 8 12 16 20 24 28 31Bits

Optionen

Ab hier kommen die Daten...

Hea

der

Absender Portnummer

Sequenznummer

Reserviert Flags Fenster

Dringlichkeitszeiger

Offset

Fuellzeichen

Pruefsumme

Bestaetigungsnummer

Empfaenger Portnummer

Bild 2.7: DasTCP–SegmentFormat


AbsenderPortnummer 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 GroßedesHeadersin 32 Bit Wortenan.OhneOptionensindes5.Damit kanngenaubestimmtweden,wo derDatenbereichdesSegmentsbeginnt.

Flags VerschiedeneFlagszurKommunikationssteuerung(SYN,ACK,.. . )

Fenster Mit diesemWertwird dieGroßedesBuffersangezeigt,dervoneinemEndknotenfur dieseVerbindungreserviertwurde.Der sendendeKnotendarf keinesfalls mehrDatenals die angegebenePuffergroßesenden,ohneauf denEingangeinerBestati-gungzuwarten.

Prufsumme EinePrufsummeuberdasgesamteSegment(DatenundHeader)

Dringlichk eitszeiger Wird beibesondersdringendzuverarbeitendenPaketengesetzt.Wenngesetztenthalt diesesFeldalsWertdieEndadressedesDatenfeldes,dasalsdringlichgilt

2.3. KOMMUNIKATIONSABLAUF EINERTCP–VERBINDUNG 15

Optionen VerschiedeneOptionenzur Kommunikationwie etwa die maximaleSegment-große

Fullzeichen Zum AuffullenderOptionszeileauf32 Bit

2.3 Kommunikationsablauf einer TCP–Verbindung

Die meistenNetzwerkdiensteim Internetarbeitenmit TCP als Transportprotokoll. AusdiesemGrundsoll hiereinmaldetailliertderKommunikationsablaufeinertypischenTCP–Verbindungbeschriebenwerden.DasVerstandnisdiesesAblaufsmachtunsspaterdasEin-richteneinerFirewall erheblichleichterundvermeidetFehler, diesonstauftretenkonnten.

EinetypischeVerbindungmit TCPwaredie KommunikationeinesWeb–Browsersmit ei-nemWebserveruberdasHypertextTransferProtocol(HTTP).DiePortnummerdesWebser-versist standardmaßigdie80,derWeb-Client(alsoderBrowser)nimmtsicheinebeliebigefreiePortnummerabder1024.In unseremBeispielwird esdiePortnummer12345sein.

Der ersteSchritt der KommunikationzwischenWeb–Clientund Webserver bestehtdar-in, daßder BenutzerdesClients eine Adressein den Browser – also den Client – ein-gibt. DieseAdressewird in eineIP–Adresseumgewandeltund der Client bekommtvomBetriebssystemeinenfreien Port oberhalb1024(alsoeinensogenanntenunprivilegiertenPort) zugewiesen.In unseremBeispielist dasderPort12345.Mun schicktjetzt derClientein HTTP–Paket andenServer. Die Transportschichtund ihr Protokoll TCPerkennt,daßessich um eineneueVerbindunghandeltund setztdassogenannteSYN–Flag im Flag–BereichdesTCP–Segment–Headers.Webserverbenutzen– sofernnichtandersangegeben– standardmaßigdenPort80.Esergibt sichalsofolgendesBild:

Web−ServerWorkstation mit Browser

IP−Adr.: 123.45.67.89 IP−Adr.: 10.11.12.13Port 12345 Port 80

Protokoll: TCPAbsender−IP: 123.45.67.89Absender−Port: 12345Empfaenger−IP: 10.11.12.13Empfaenger−Port: 80Flags: SYN (Aufforderung zur Verbindungssynchronisation)

� � ��

� ��

� � ��

��

��

Bild 2.8: Client bittet umVerbindungsaufbau

Der Client schicktin demHeadernebendemSYN–Flag– 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 erkenntaufgrunddesSYN–Flags,daßessich umeineneueVerbindunghandeltund reservierteinenneuenSocket fur die Kommunikation


mit demClient.Er schicktjetzteinPaketzuruck,dassowohl dasACK–Flag(Acknowledge– Bestatigung),alsauchwiederumein SYN–Flaggesetzthat.Man sprichtjetzt von einerhalb–offenenVerbindung.



Protokoll: TCPAbsender−IP: 10.11.12.13Absender−Port: 80Empfaenger−IP: 123.45.67.89Empfaenger−Port: 12345Flags: ACK (Bestaetigung der Anfrage)

SYN ( Aufforderung zur Verbindungssynchronisation)

� � ��

� ��

��

��

��

��

Bild 2.9: BestatigungderBitte um Verbindungsaufbau

Die 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 demACK–Flagablaufen.Die Tatsache,daßin allen PaketendesServersdasACK–Flaggesetztist, in der erstenAnfragedesClientsjedochnicht,wird beimAufbaueinerFirewall ein wichtigesKriterium sein.

Im nachstenSchrittbestatigt derClient seinerseitsdenEmpfangderAntwort desServers.Von nunanwird nur nochdasACK–Flaggesetztsein.WederServer, nochClient werdenim Lauf derVerbindungdasSYN–Flagnochmalbenutzen.

2.3. KOMMUNIKATIONSABLAUF EINERTCP–VERBINDUNG 17



Protokoll: TCPAbsender−IP: 123.45.67.89Absender−Port: 12345Empfaenger−IP: 10.11.12.13Empfaenger−Port: 80Flags: ACK (Bestaetigung)

� � ��

� ��

��

��

��

��

Bild 2.10: Die Verbindungist hergestellt

Bei jederweiterenBestatigung(alsojedemweitererhaltenenACK–Flag)erhohensowohlClient, als auch Server die Sequenznummerndes letztenempfangenenPaketes.DamitbestatigensiealsodenEmpfangdesPaketesundgebengleichzeitigbekannt,welchesPa-ketsiealsnachsteserwarten.Die jeweiligeGegenseitekannalsoallePaketemit nierigerenSequenznummernwegwerfen.

Um eineVerbindungabzubauenwird ein weiteresFlagbenutzt,dasaberfur denAufbauvon Firewallsystemenunwichtigist. Zusammenfassendkonnenwir alsofesthalten:

DasSYN–Flagist gesetzt,wennClient und Server jeweils ihr erstesPaket schicken.Beiallen folgendenPaketenist dasACK–Flaggesetzt.Ein Paket, in demnur dasSYN–Flaggesetztist mußzwangslaufigeineAnfrageeinesClientsaneinenServersein.

Nachdemnundie GrundlagenderTCP/IP–Kommunikationgeklartsind,ist esanderZeit,dieGrundlagenderFirewall–Technikenanzusprechen.Die in diesemKapitelbesprochenenFelderderTCP–undIP–HeaderwerdendabeiKriterien fur dieAuswahl sein.

Kapitel 3

Grundlagen der Fir ewalltechnik

Die hier vorgestellteFirewall ist einesogenanntePaketfilter–Firewall. Dabeigehtesalsodarum,die im letztenKapitel angesprochenenPaketezu bewertenundanhandverschiede-nerKriterienzuentscheiden,ob einPaketpassierendarf,odernicht.

Eine solchePaketfilter–Firewall arbeitetin der von unsbesprochenenLinux–VersionmiteinerListevonAnnahme–oderAblehnungskriterien.DarausentstehensogenannteRegeln,diegenaubestimmen,ob einPaketpassierendarfodernicht.DieseKriteriensind

� Netzwerkschnittstelle

� IP–Adressen

� TCP/UDPPortnummernbzw. ICMP Nachrichtentypen

� SYN–undACK–Flags

� Die Flußrichtung(eingehendesoderabgehendesPaket)

All dieseInformationenzeigen,daßdieFirewall alsoaufderVermittlungs–und Transport-schichtdesTCP/IP–Schichtenmodellsarbeitet.

Fur beideFlußrichtungen(ankommend– Input undabgehend– Output)stehenjeweils ei-geneFilter zur Verfugung.Der grundlegendeMechanismusist dabeider, daßfur beideRichtungeneineganzeAnzahlvon hintereinanderfolgendenRegelnexistieren,die hinter-einanderabgearbeitetwerden.So entstehtebeneinesogenannteKette (engl. chain) vonRegeln,daherderNameip–chains.

DieseKettevon Regeln wird solangeabgearbeitet,bis entwedereineRegel zutrifft, oderdasEndederKetteerreichtist.

18

19

Abgehendes Paket

Abbruch

Abbruch

trifft zuRegel 1

Abbruch

Abbruch

Netzwerk−Schnittstelle

Input−Chain

Ankommendes Paket

trifft zu

JaNein

trifft zu

JaNein Regel 2

Regel 3

Annahme

Output−Chain

Regel 1trifft zu

JaNein

Abbruch

Abbruch

trifft zuRegel 3

trifft zuRegel 2

Ja

Ja

Ja

Nein

Nein

Nein

Bild 3.1: Input–undOutput–Chains

20 KAPITEL 3. GRUNDLAGENDER FIREWALLTECHNIK

3.1 Die Voreinstellungfur Paketfilter

Aus demletztenBild kannder Eindruckentstehen,daßdie Regeln grundsatzlichso auf-gebautsind,daßsieeinzelnePaketeablehnen,ansonstenaberalleanderenannehmen.Dasist naturlich moglich, aberwedernotwendig,nochempfehlenswert.Linux–Firewalls bie-ten zwei verschiedeneStrategien an, nachdenendie Firewall arbeitet– die sogenanntenPolicies:

� Grundsatzlichwird allesabgewiesen;nur explizit durchRegelnzugelassenePaketewerdenakzeptiert.DiesePolicy heißtDENY.

� 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,wiedasEinrichtenderDENY–Methode.

Zusammengefasstmußalsogesagtwerden,daß– zumindestensfur Pakete,die ausdemunsicherenNetzins sicheregelangensollen– dieStrategieDENY vorzuziehenist.

Auf denbeidenfolgendenSeitensinddiebeidenunterschiedlichenStrategiennochmalalsFlußdiagrammedargestellt.

3.1. DIE VOREINSTELLUNGFUR PAKETFILTER 21

Wird angenommen

ACCEPTtrifft zu

JaNein

trifft zu

JaNein Regel 2

Regel 3

Regel 1trifft zu

JaNein

IP−Paket

Firewall Policy DENY

Paket abweisen

Wird angenommen

ACCEPT

Wird angenommen

ACCEPT

Bild 3.2: Die DENY–Policy

22 KAPITEL 3. GRUNDLAGENDER FIREWALLTECHNIK

trifft zu

JaNein

trifft zu

JaNein Regel 2

Regel 3

Regel 1trifft zu

JaNein

IP−Paket

Firewall Policy ACCEPT

DENY

DENY

DENY

Paket annehmen

Wird abgelehnt

Wird abgelehnt

Wird abgelehnt

Bild 3.3: Die ACCEPT–Policy

3.2. REJECTODERDENY 23

3.2 REJECT oder DENY

Die Linux–Firewall 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 hohenSicherheitsanforderungen–immerbesser, Paketemit DENY einfachzu verwerfen,alseineFehlermeldungzuruckzu-geben.Dashatdrei Grunde:

� DurcheineFehlermeldungwird derDatenverkehrauf demNetzunnotig vergroßert.

� Fehlermeldungenkonnenals Teil einerDenial–of–Service–AttackStrategie einge-setztwerden.Wenn etwa ein Angreifer, der einenRechnerim Internetblockierenwill, seineIP–Adresseauf 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 Zusammenfassung

Zusammenfassendkonnenwir also feststellen,daßes zwei wesentlicheStrategien (Po-licies) gibt, die eine Paketfilter–Firewall ausmachen.Entwederwir nehmenalle Pakete,außerexplizit verbotenen,an – Policy ACCEPT, oderwir verweigerndie AnnahmeallerPaketeaußerexplizit erlaubten– Policy DENY.

Zum Umgangmit einzelnenPaketenstehenunsdrei Methodenzur Verfugung:

ACCEPT DasPaketwird angenommen

DENY DasPaketwird stillschweigendverworfen

REJECT DasPaket wird abgelehnt,abereswird eineICMP–FehlermeldungandenAb-senderzuruckgeschickt.

Grundsatzlich unterscheidenwir zwischender Input– und Output–Chain,alsoder Kettevon Regelnfur eingehendebzw. ausgehendePakete.

Kapitel 4

Filter n von eingehendenPaketen

EineFirewall istgrundsatzlichin derLage,sowohl ankommende,alsauchabgehendePake-te zu filtern. In derRegel ist jedochdie FilterungderankommendenPaketedie wichtigereTechnik,wollen wir dochvermeiden,daßAngriffe von außen,alsoausdemunsicherenNetz, auf unserzu schutzendesNetz stattfinden.In diesemKapitel werdendie Kriterienbesprochen,nachdenenwir eingehendePaketefiltern konnen.

4.1 Filter n nach IP–Adr essen

Auf der Ebeneder Vermittlungs–und Transportschichtist die IP–Adressedie einzigeMoglichkeit, herauszufinden,werein Paket anunsgeschickthat.DieseInformationstecktim IP–Header, alsoderInformation,dieunsdieVermittlungsschichtubermittelt.

Die Authentizitat dieserInformationist grundsatzlichfragwurdig.Es ist ein leichtes,dieIP–AdressedesSenderseinesPaketeszufalschen,auchwenndadurcheinefunktionierendeKommunikationin derRegelunmoglichgemachtwird.

Grundsatzlichkonnenwir sowohl Absender–, alsauchEmpfanger–IP–AdressenalsKrite-rien fur eineFirewall benutzen.

4.1.1 Filter n nachAbsender–Adressen

DasKriterium fur die Entscheidung,ob wir ein Paket durchlassenodernicht ist hier al-so die AdressedesSenders,die unsja im IP–Headerzur Verfugungsteht.Hier kommenverschiedeneTechnikenzur Anwendung.

Ablehnenvon gefalschtenoder ungultigen Adr essen

Esist naturlich nicht soeinfachmoglich,gefalschteAdressenalssolchezuerkennen,aberesstehenunsjedochein paarMittel zur Verfugung,offensichtlichfalscheAdressenabzu-weisen.SechsHauptgruppenvon solchenAdressensolltenwir grundsatzlichablehnen:

1. Die eigeneIP–Adresse:Niemalskannein regular eingehendesPaket vom eigenenRechnerstammen.Esmußsichalsozwangslaufigum eineFalschunghandeln.

2. Die IP–Adressen,die fur lokale NetzeohneInternet–Anschlußreserviertsind: 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.255

KlasseB 172.16.0.0bis 172.31.255.255

KlasseC 192.168.0.0bis192.168.255.255

24

4.2. FILTERNNACH PORTNUMMERN 25

Pakete,die dieseAdressenhabenundausdemInternetkommen,konnenSiebeden-kenlosablehnen.

3. Multicast–Adressender KlasseD: Hierbeihandeltessichum reservierteAdressenfur sogenannteMulticast–Broadcasts,wie sie etwa fur Audio– oder Video Ubert-ragungan mehrereEmpfangerverwendetwerden.DieseAdressendurfen zwar alsEmpfanger–Adressen,niemalsjedochalsAbsendervorkommen.EshandeltsichumdieAdressenim Bereichvon224.0.0.0bis239.255.255.255.

4. Alle KlasseE–Adressen:AdressendieserKlassewarenfur expeimentelleErweite-rungenvorgesehenund werdengrundsatzlich nicht offentlich vergeben.Sie liegenim Bereichvon 240.0.0.0bis 247.255.255.255. In derRegel werdendieseAdressenohnehinnur von US–Militarsund –Geheimdienstenverwendet.Im Internetsolltensienieauftauchen.

5. Loopback–Adressen:Die reservierteAdresse127.0.0.1ist eineAdresse,die immerdenlokalenRechnermeint.Ein Paket,dasausdemInternetkommtunddieseAdresealsAbsenderadresseeingtragenhatkannniemalseineechteAdressesein.

6. BroadcastAdressen:Broadcast–AdressensindAdressen,die in Netzenbenutztwer-den,ummehrereSystemegleichzeitiganzusprechen.SolcheAdressensindalsEmpfanger–Adresselegal,alsAbsender–Adressejedochnie.

BestimmteAdr essenherausfiltern

EsexistierenbestimmteAdressen,vondenenmanweiß,daßvon ihnenoft Angriffe ausge-hen.Esist moglich,solcheAdressen,seienesHost–oderganzeNetz–Adresseneinfachzusperren.Auf deranderenSeiteist esauchmoglich, bestimmtenAdressendenZugriff aufbestimmteDiensteeinesNetzeszuzulassen.Sokannetwa die Filliale unsererFirma,vonderwir genaudie IP–Adressewissen,auf unserenDatenbank–Server zugreifen,wahrendsonstniemandaskonnensoll.

4.1.2 Filter n nachEmpfanger–Adressen

Das Feld der Empfanger–Adresseist 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, dessenEmpfanger–IP–AdressenfelddieAdressediesesWebserversenthalt, mußalsodurchgelassenwerden,alle anderenPaketekonntenwir sperren.

4.2 Filter n nach Portnummern

Portnummernsind InformationenausderTransportschicht,alsoentwederausdemUDP–HeaderoderdemTCP–Header. Sie gebenan, welchesProgrammauf der Anwendungs-schichtein eingehendesPaket erhalt (Empfanger–Portnummer) odervon welcherAnwen-dungeinPaketgeschicktwurde(Absender–Portnummer).BeideFallesindwichtigeInfor-mationenfur eineFirewall.

4.2.1 Filter n nachder Absender–Portnummer

Hier mussenwir unterscheiden,ob essich um ein Paket handelt,daseineAnfragenacheinemlokalenServicebeantragt(alsoein Client von außerhalb,dereinenServicevon in-nerhalbnutzenwill). In diesemFall wird die PortnummereineNummerzwischen1024und65535seinmussen.

26 KAPITEL 4. FILTERNVON EINGEHENDENPAKETEN

Im umgekehrtenFall, alsowenneinClientvon innerhalbeinenServicevonaußerhalbnut-zenwill, dannwird eineingehendesPaketdieAbsender–PortnummerdesjeweilsgenutztenDiensteshaben1.

4.2.2 Filter n nachder Empfanger–Portnummer

DiesesFeldist fur unssehrinteressant,weil hier – zumindestensbei eingehendenPaketen– die PortnummerdesDienstessteht,denein Uservon außerhalbnutzenwill. Dasheißt,hier ist derOrt, wo wir von vornehereinnur die Paketedurchlassen,die PortnummernvonDienstenenthalten,diewir auchanbietenwollen.

Auch hier gibt esjedochdenzweitenFall, namlichdie Antwort einesfremdenServersaufeineNachfrageeineslokalenClients.In demFall liegendie Empfanger–PortnummernimunprivilegiertenBereichzwischen1024und65535.

4.3 Filter n nach TCP–Status–Flags

Auch 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, daßmit ihrer Hilfe un-terschiedenwerdenkann, ob ein Paket eine Anfrage von außenoder eine Antwort aufeine Anfrage von innen enthalt. Pakete,die Antworten fremderServer enthaltenhabengrundsatzlichdasACK–Flaggesetzt.Firewall–Regelnkonnendaherz.B.entscheiden,daßin ein interneszuschutzendesNetznurPaketemit diesemFlaghereingelassenwerden.

4.4 Angriffsf ormen von außerhalb

Um eineFilterungeingehenderPaketeuberhauptsinnvoll zu nutzen,ist esnotwendig,diegangigenFormenvon Angriffen von außerhalbzu kennen.Im Folgendensollenkurz diehaufigstenAngriffsformenbeschriebenwerden,die keinenormalenZugriffe auf Dienstesind.

4.4.1 Portscans

Ein 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 außeneignen.DaskostetwenigerZeit und istdaherauchwenigerleicht zuerkennen.

1Siehe/etc/services

4.4. ANGRIFFSFORMENVON AUSSERHALB 27

TypischePorts,diegernegescanntwerdensindin derTabelleim Anhang(Seite69) aufge-listet.

Mit einerinstalliertenFirewall werdensolchePortscannsnaturlich bemerkt.Allerdings–unddazuhabenwir ja eineFirewall – bedeutetderScanansichnochkeinerealeGefahr.Jemandversuchtetwas uberunserSystemherauszufinden,wird jedochvon der Firewallabgewiesen.. .

4.4.2 Denial–of–Service–Attacks

EinewesentlichgefahrlichereArt desAngriffs ist diesogenannteDenialof ServiceAttack,oft alsDoSabgekurzt.Hierbeiwird versucht,einenComputerderartmit Datenpaketenzuuberfluten,daßerentwederkeineanderenPaketemehrverarbeitenkann,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:

TCP–SYN–Flooding

DieseAngriffsformbestehteinfachdarin,dendreiteiligenHandshakeeinerTCP–Verbindung(sieheSeite15) zu unterbrechen.Wenn ein Client einemServer eine Anfrage stellt, soschickter demServer ein Paket mit gesetztemSYN–Flag.Der Server schicktalsAntwortein Paket mit einemgesetztenSYN– undACK–Flag.Damit ist die Verbindunghalboffen.WennderClient jetztkeineAntwort mit gesetztemACK–Flagschickt,dannhalt derServerdieseVerbindungin derRegel fur etwa 5 Minutenoffen.

WennderClient jetzt erneut(mit andererSequenznummer)eineSYN–Nachfrageschickt,dannmußderServereinenneuenKanaloffnen.SogehtdasSpielchenweiter, bisderServerkeineKanalemehrzur Verfugunghat.Im schlimmstenFall wird derServerdannganzlichabsturzen,im mindestenFall kannerkeineweiterenDiensteanandereanbieten.

Die SYN–FlagAnfragepaketewerdennormalerweiseeinegefalschteSender–IP–Adressehaben,derSendererwartetja keineAntwort, erwill ja nur storen.

Linux bieteteinespeziellgegendieseAngriffsform gerichteteKerneleigenschaft,die so-genanntenSYN–Cookies.Damit kannsich ein Linux–KernelerfolgreichgegenAngriffedieserArt wehren.

PING-Flooding

DasProgrammping wird benutzt,um festzustellen,ob ein betimmterRechneruberdasNetz erreichbarist. DiesesProgrammschickteineICMP–Echoanforderungan einenbe-stimmtenRechnerundwartetdannaufebendiesesEcho.Die Tatsache,daßessichhierumICMP (sieheSeite12) handelt,zeigtschon,daßping hier nicht uberdie Netzwerkschicht(Vermittlungsschicht)hinausgeht.EsexistierenalsokeinerleiPorts.

Wennein RechnereinenanderenRechnermit ping–Anfragenuberhauft, sokannesdazukommen,daßdieserandereRechnerkeineBandbreitemehr fur andereNetzwerkdiensteubrighat,er ist alsoauchfaktischlahmgelegt.

AltereUnix–Versionen(nichtLinux) warenauchanfallig gegendassogenannteTodesping,eineEchoanforderung,die zu großeDatenpaketeverschickt.DiesealtenRechnerkonntendanntatsachlichzumAbsturzgebrachtwerden.

28 KAPITEL 4. FILTERNVON EINGEHENDENPAKETEN

UDP-Flooding

DasUDP–Protokoll eignetsichhervorragendfur Denial–of–Service–Angriffe. Es ist ver-bindungslos,d.h., es existiert keine Flußkontrolle, kein Handshake, keine Sequenznum-mern.. .Es ist alsosehreinfach,einenRechnermit UDP–Anfragenderartzu uberhaufen,daßkeineBandbreitemehrfur andereNetzwerkdiensteubrigbleibt.

UDPist traditionellabersowiesofur DiensteinnerhalbdeslokalenNetzesbestimmt,Dien-ste im Internetbenutzenfast immer TCP als Transportprotokoll. Viele Firewalls lassendahergrundsatzlich keine oder nur ein paarausgewahlte UDP–DienstanfragenausdemunsicherenNetzzu.

ICMP–Redir ect–Angriff

Der Nachrichten–Typ 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 5

Filter n von ausgehendenPaketen

DasFiltern 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 IP–Adr essen

Auch hier unterscheidenwir wiederzwischenAbsender– und Empfangeradresse.BeideFalle bietenein paarnennenswerteKriterien fur einePaketfilterfirewall:

5.1.1 Filter n nachAbsender–Adresse

DasKriterium fur dieSenderadressefur abgehendePaketeist simpel.Esmußsichumeineim lokalenNetzgultigeAdressehandeln.Also entwederumeinenbestimmtenAdresspool,oderumeineklareListevonAdressen,diewiederumentwederfestvergebensind,odervoneinemDHCP–Serververwaltetwerden.

Bei einerVergabevon AdressenuberDHCP kommt esbeim Aufbau der VerbindungzueinerspeziellenSituation,dieabernurdanneineRollespielt,wennsichderDHCP–ServeraußerhalbdeszuschutzendenNetzesbefindet.Und dasist grundsatzlichkeineguteIdee.

5.1.2 Filter n nachEmpfanger–Adresse

Bei derFragederFilterungnachderEmpfanger–AdresseabgehenderPakete,gibt eszweiwesentlicheBereiche.Wir unterscheidenhier grundsatzlich,ob dasPaket aneinenServerim Internetgerichtetist, oderob esan einenClient im Internetgeht,dereinenServer imLAN angesprochenhatte.

1. PaketeaneinenServer im Internet:Hier ist esmoglich,bestimmteIP–AdressenoderDNS–Namenkomplettzusperren,weil esunerwunschtist, daßausdemLAN herausdieseDiensteangenommenwer-den.Eskannauchz.B. ein bestimmtesProtokoll (z.B. POP3oderIMAP) an einenbestimmtenRechnergebundenwerden,alle anderenAdressenwerdennicht durch-gelassen.. .

2. PaketeaneinenClient im Internet:UnserNetzhatvielleichteinpaaroffentlicheServer, dievonjedemClientausbenutztwerdendurfen(Webserver, FTP–Server.. . ), eshataberandererseitsauchDiensteimAngebot,die nur fur bestimmteRechnerim Netz zur Verfugungstehensollen.Soetwa die Filiale in eineranderenStadt,derenIP–Adressewir kennen.In so einem

29

30 KAPITEL 5. FILTERNVON AUSGEHENDENPAKETEN

Fall ist esdurchaussinnvoll, nicht nur die eingehendenPakete,sondernebenauchdieausgehendenPaketevon derFirewall unterdruckenzu lassen.

5.2 Filter n nach Portnummern

Auchhierunterscheidenwir wiederzwischenAbsender– undEmpfangerport.Fur ersterenist zubemerken,daßeinAbsenderporteinesClientsausdmlokalenNetzgrundsatzlichei-nePortnummerausdemunprivilegiertenBereichhabensollte,ServerprozessedeslokalenNetzeskonnenwiederumnur die zugelassenenPortsbenutzen.Hier habenwir wiederumeinedoppelteMoglichkeit, zu verhindern,daßungewollte 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 TCP–Status–Flags

Wie bei den ankommendenPaketen,konnenwir auchbei den abgehendenPaketendieStatusflagsnutzen,um zu entscheiden,ob ein Paket von einemClient oder von einemServerstammt.

� Wennein lokalerClient einenDienstim Internetanspricht,dannist im erstenPaketnurseinSYN–Flaggesetzt,nicht jedochdasACK–Flag.Alle weiterenPaketehabennurnochdasACK–Flaggesetzt,nicht jedochdasSYN–Flag.

� WenneinlokalerServereinenDienstim Internetanbietet,dannsindim erstenPaket,daser verschicktbeideFlags(SYN und ACK) gesetzt,alle weiterenPaketehabennurdasACK–Flaggesetzt.

Kapitel 6

Gestaltungeiner Fir ewall mitLinux

Nachdemnunalle 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 Standard–Ketten

Wir habenbereitsgesehen,daßeineFirewall unterLinux ausvieleneinzelnenRegelnbe-steht,die zu einerKette(chain) zusammengefasstwerden.StandardmaßigexistierendreiKetten,eskonnenaberbeliebigvieleweitereKettenerstelltwerden– z.B.spezielleRegelnfur einenModemanschlußoderahnliches.Die dreiStandard–Kettensind input,outputundforward.

WenneinPaketvonaußenaneinerbeliebigenNetzwerk–Schnittstelleankommt,dannwirdseinHeadermit jederRegel der input–Chainverglichen,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 input–Chain– die output–Chainin Kraft.

Wennein Paket nicht fur denRechnerbestimmtist, auf demdie Firewall lauft, sondernanandereRechnerweitergeleitet(geroutet)werdensoll, danntritt die dritteRegelkettezu,die forward–Chain.DieseRegelkettekannnebendennormalenRegelnnocheineweitereFahigkeitanbieten,dassogenannteMasquerading.HierbeihandeltessichumdieFahigkeitdesKernels,zuroutendePaketezumaskieren,sodaßvonaußenderEindruckerwecktwird,siekamenausschließlichvon demFirewall–Rechner. DashatzweiVorteile:

� Ein internesNetzwerkkannmit reserviertenIP–Adressenarbeiten,trotzdemkannjederRechnerdesinternenNetzesuberdie Firewall nachaußenins Internetgelan-gen.

� Vonaußenist dieStrukturdesinternenNetzesnichtsichtbar, weil esnachaußenhinnur die IP–Adresseder Firewall gibt. Ein Angriff auf einenRechnerinnerhalbdesNetzesist vondaherschonunmoglich,daßjederRechnerinneneineAdressehat,dieim Internetgarnicht geroutetwerdendarf.

31

32 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX

ZusammengefasstkonntemaneineFirewall mit all ihrenRegelkettenalsofolgendermaßendarstellen:

Che

cksu

mm

e

San

ity−

Che

ck

Dem

asqu

erad

e

Routing OutputChain

InputChain

ForwardChain

Deny/Reject

Deny/RejectDeny/Reject

Accept

Accept

Acceptlocal

external

Bild 6.1: ArchitekturderIP-Chainsim Kernel

Die 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 jedochderAufbauvonFirewall–Regelnnicht,wasmanbei jedemStartvonHandubernimmt.Wirwerdenim Gegenteilnaturlich Scripteerstellen,die die Regelndefinierenunddie bei je-demStartausgefuhrtwerden.JedenotwendigeAnderungvonRegelnsollteauchimmerindiesenScriptenstattfinden,dennVon Hand eingegebeneFir ewall–Regelnsind nachdemnachstenNeustart verschwun-den!

6.2 DasHandwerkszeug:ipchains

DasProgramm,mit demwir Firewall–Regelnerstellen,bearbeitenoderloschenheißtip-chains und ist sozusagenein Werkzeugzur ManipulationderRegeltabellenim Kernel.DiesesProgrammsollte im Verzeichnis/sbin liegenundnur vom Systemverwalterauf-gerufenwerden.Als typischesUnix–Programmwird esausschließlichuberdie Komman-dozeilegesteuert,also uber einenBerg von verschiedenenKommandozeilenparametern.Dasist von daherwichtig, daßwir ja Scripteschreibenwollen, die die einzelnenRegelnerstellen.Nur mit einemKommandozeilenorientiertenProgrammkanndasgelingen.

ipchains ist einProgramm,dasfur jedeFirewall–Regeleinmalaufgerufenwerdenmuß.Die wichtigenParameterwerdenjetzt kurzdargestellt.EinevollstandigeBeschreibungderParameterfindenSieaufderentsprechendenMan–Pageipchains(8) undim IPCHAINS-HOWTO.

6.3. FORMAT DERANGABEN 33

ipchains-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 SYN–Flag einer TCP–Nachrichtmuß gesetzt,dasACK–Flagdarf nicht gesetztsein.DasPaket ist alsodasersteeinesVerbindungsaufbauesundkommtvomClient.

! -y DasACK–FlageinerTCP–Nachrichtmuß gesetztsein.Dasheißt,dasPaket ist entwederderzweiteTeil desVer-bindungsaufbauesoder, esist ein Teil einerbestehendenVerbindung.Ist weder-y noch! -y gesetzt,werdendieTCP–Flagsnicht uberpruft.

-s Adresse [ Port] Absender–AdressedesPaketes.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] Empfanger–Adressedes Paketes. Ports wie bei derAbsender–Adresse.

-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 Angaben

6.3.1 IP–Adr essen

EineFirewall–Regel kannsowohl eineSender–, alsaucheineEmpfangeradressebeinhal-ten. In diesemFall gilt die Regel dannebennur fur dieseAdresse.Statt der AdressenkonnenauchdieRechnernamenangegebenwerden,dashatabereinpaargewichtigeNach-teile.Zur NamensauflosungmußeinfunktionierendesDNS–Systemvorhandensein.Diese


Voraussetzungkonnte– zumindestensam AnfangeinerRegelkette– nochnicht gegebensein,wennDNS selbsteinerBeschrankungunterliegt. Es ist dahergrundsatzlich ratsam,stattNamenebenIP–Adressenzuverwenden.ZumAnderenkonnenDNS–Namenleichtergefalschtwerden,alsIP–Adressen.

IP–Adressenkonnendazunochmit einerMaske versehenwerden,die die signifikanntenBits derAdresseangibt.DieseMaske wird alsBitmaske realisiertundeinfachmit einemSlash(/ ) hintenandieAdresseangehangt.Die Bedeutungist einfach,die Adressangabe

192.168.100.123/24

bedeutet,daßdieersten24Bit derAdressangabemit dergefundenenAdresseubereinstim-menmussen,damit die Regel greift. In diesemBeispielsind dasalsoalle Adressen,dievorne192.168.100 stehenhaben.EineMaske /32 bedeutetalso,daßdieAdresseexaktubereinstimmenmuß,eineMaske /0 bedeutet,daßkeinBit ubereinstimmenmuß,alsoalleAdressengemeintsind.Dafur ist auchdieAbkurzungany/0 zulassig.

6.3.2 Ports

Portskonnensowohl alsPortnummer, alsauchalssymbolischeNamenangegebenwerden,wie sie in /etc/services eingetragensind. Allerdings hat der Eintragdessymboli-schenNamensdenNachteil,daßdieseNamennicht immergleichsind,siesindnicht festvorgegeben.Bei einemDistributionswechselkonnteesvorkommen,daßeineFirewallregelnichtmehrfunktioniert,wennebendieNamenderPortssichveranderthaben.Andererseitsist naturlich einNameaussagekraftiger, alseineNummer.

6.4 Praktischer Aufbau einer Fir ewall

Eine 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 mußselbsterstelltwerden,auchwennDistributorenwieetwa S.u.S.EschonvorgefertigteScriptsenthalten.Wir werdenunshier ein solchesexem-plarischesScripterstellen.

6.4.1 Grundeinstellungen

Zum 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 D

6.4. PRAKTISCHERAUFBAU EINERFIREWALL 35

CLASS_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

Der 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 -F

Alle 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 REJECT

Ab 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 ACCEPT

6.4.2 Ein paar Techniken zur Abwehr von gefalschtenPaketen

Nun habenwir eine Grundeinstellung,mit der sich bereitsarbeitenlasst.Allerdings istbisheraußerdemlokalenLoopbacknochnichtserlaubt.Bevor wir jetzt weitereRegelnerstellenist essinnvoll, nochein paarSicherheitsmechanismengegenSYN–FloodingundgefalschteIP–Paketeeinzubauen.Der Linux–Kernelenthalt bereitseinigedieserMecha-nismen,die wir nur noch aktivierenmussen.Dazu stehenein paarsehrLinux–typischeWegezur 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.


� /proc/sys/net/ipv4/conf/*/rp filterDasVerzeichnis/proc/sys/net/ipv4/conf enthalt fur jedesIP–InterfaceeinUnterverzeichnis,in demjeweilseineDateirp filter liegt.DieseDateienermogli-chenes,diesogenannteSource–Address–Verificationeinzuschalten.

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_filterdo

echo 1 > $idone

6.4.3 Ausfiltern offensichtlich falscher Adr essen

EsgibteinpaarAdressen,diewir grundsatzlichablehnenkonnen,weil sienielegalausdemexternenNetz(Internet)kommenkonnen.Dazuzahlt zuersteinmaldieeigeneIP–Adresse,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 -l

Die beidenverwendetenBegriffe $EXTERNALINTERFACEund$IPADDRhattenwir jaobenbeiderKonstantendefinitionfestgelegt. Dasangehangte-l bedeutet,daß,fallsdieseRegel zutrifft eineMeldungandensyslogd gehtundderVorfall protokolliert wird.

DernachsteSchrittist dasVerbotallerein–undausgehenderPaketemit 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 DENY


Noch eine Adressform,die denkbarungultig ist, ist die Verwendungeiner Loopback–AdressealsAbsender–Adressevom externenInterface.Wederein–nochausgehendePa-ketedurfendasvorweisen:

# Pakete mit Loopback als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENY

Als nachstesfiltern wir illegaleBroadcastAdressenaus,dasheißtBroadcastAdressen,diedieBroadcast–Absender–AdressealsEmpfanger–Adressehabenoderumgekehrt:

# 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

JetztfolgendieAbweisungderKlasse-DAdressenim Absender–Feld.KlasseD–AdressensindsogenannteMulticastAdressen,diegrundsatzlichnur im Empfanger–Feldauftauchendurfen.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 REJECT

Als nachstesverbietenwir alle Arten von Klasse–EAdressen,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 DENY

NebendenreserviertenAdressenderverschiedenenKlassen,hatdiezentraleVergabestellefur Internetadressen(IANA) nocheinige weitereA– und B–KlasseAdressenreserviert.DieseAdressendurfen nicht im offentlichenInternetauftauchen,also schließenwir sieaus.Eshandeltsichumdie Netzadressen

� 0–2.*.*.*

� 5.*.*.*

� 7.*.*.*

� 23.*.*.*

� 27.*.*.*

� 31.*.*.*

� 37.*.*.*

� 39.*.*.*

� 41–42.*.*.*

� 58–60.*.*.*


� 65–69.*.*.*

� 80–95.*.*.*

� 96–126.*.*.*

� 217–219.*.*.*

� 220–223.*.*.*

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 DENY


ipchains -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

Damit hattenwir die offensichtlichungultigenAdressenjetzt ausgefiltert.Alleine dasVo-lumendieserRegelnzeigtnochmaldeutlich,daßsienicht 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 ICMP–Nachrichten filter n

ICMP, dasInternetControlMessageProtocol,wird benutzt,um Fehler– bzw. Kontrollme-chanismenzu tansportieren.Esarbeitetauf der IP–Schichtundsomiteigentlichnicht mitPortnummern.TrotzdemunterscheidetICMP verschiedeneNachrichtentypen,die ausderSichtderFirewall wie Portnummernverwendetwerden.EineListe derwichtigstenNach-richtentypensamtihrenPortnummernfindenSieim Anhangauf Seite71.

Vier ICMP–TypenmussengrundsatzlichdieFirewall 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 ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 4 -d $ANYWHERE-j ACCEPT

Die Darstellungist mittelsBackslashin zweiZeilengebrochen,dasdientnurderbesserenLesbarkeit, nichtderFunktionalitat.Wir erlaubenalsoeingehendePaketevomTyp ICMP–4 vonuberallhermit unsererAdressealsEmpfanger, sowieausgehendePaketediesesTyps,von unsuberallhin.

Genausoverfahrenwir mit derStatusmeldungparameter-problem (ICMP–Typ 12).Wir erlaubendieseTypen von uberall her zu unsererAdresseund von unsererAdresseuberallhin:





Bei der Fehlermeldungdestination-unreachable (ICMP–Typ 3) liegt die Sacheetwasanders.SolcheFehlermeldungenentstehennamlichwahrendeinesPortscans,wennein Angreifer versuchtherauszufinden,welchePortsgeoffnet sind. Die einfachsteFormwarejetzt,diesenTyp ganzzusperren,dasgehtaberleidernicht,denneinUntertypdieserMeldung (fragmentation-needed ) wird zwingendfur dasAushandelnder Paket-großeim Netzbenotigt. Aus diesemGrundkonnenwir alle Typ–3Nachrichtennur anden(oderdie)RechnerunseresProviderszulassen,wahrendwir denSubtypfragmentation-neededanalle erlauben:

# ICMP-Typ 3 f ur Providerrechner erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\


ipchains -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

Die letztezwingendeICMP–Nachrichtist die Statusmeldungtime-exceeded (ICMP–Typ 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\



Die wichtigstealler ICMP–Nachrichtenwird im Programmping benutzt.Mit Hilfe die-sesProgrammskannfestgestelltwerden,ob ein andererComputeruberdasNetz zu er-reichenist, odernicht. Der suchendeComputerschicktan dengesuchtenComputereinecho-request (ICMP–Typ 8). Wennder gesuchteRechnerdiesesPaket empfangt,soschicktereinecho-reply (ICMP–Typ 0 oderauchpong)zuruck.

Ublich ist es,daßwir jedenHostim Internetanpingendurfen,alsogehenTyp 8 PaketerausundTyp 0 Paketerein:

# Ausgehendes Ping erlaubenipchain -A output -i $EXTERNAL_INTERFACE-p icmp\

-s $IPADDR 8 -d $ANYWHERE-j ACCEPT

ipchain -A input -i $EXTERNAL_INTERFACE-p icmp\



WiederumalsBeispieleinereingeschranktenZulassungvon außen,erlaubenwir nur denRechnernunseresProviders,unsanzupingen:

# Ankommendes Ping nur f ur Provider erlaubenipchain -A input -i $EXTERNAL_INTERFACE-p icmp\

-s $MYISP 8 -d $IPADDR -j ACCEPT

ipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 0 -d $MYISP -j ACCEPT

Damit sind die notwendigenICMP–Nachrichtenerlaubt,die unnotigenverhindert.Jetztkonnenwir unslangsamandieechtenNetzwerkdiensteheranwagen.. .

6.4.5 Diensteauf unpri vilegierten Ports

Dienste,dieaufunprivilegiertenPortslaufen,erschwerendenAufbaueinerFirewall erheb-lich. UnprivilegiertePortshabeneineDoppelbedeutung,einerseitskonnenDienstediesePortsnutzen,andererseitskonnenClients,die andereDienstenutzen,auf diesePortnum-mernzuruckgreifen(sieheSeite15).

Mit dem TCP–Transportprotokoll 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 paarTCP–Dienstean:

HaufigeTCP–Diensteauf unpri vilegierten Ports

Ein typischesBeispielist einOpenWindow DisplayServer(TCP–Port2000).AusgehendeVerbindungenzueinemsolchenServersolltemansperren.Mit Hilfe derOption-y formu-lierenwir dieseRegelso,daßsienurfur 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 REJECT

Bei X11-Display–Servernsiehtdie Sacheahnlichaus,jedochmussenwir hier auchein-gehendeVerbindungenunterbinden.AusgehendeVerbindungenwerdenausSicherheits-grundenverboten,weil X11 grundsatzlichaucheinensicherenssh–Eingangbietet,derim-mer vorzuziehenist. X11–Display–Server benutzendie Ports6000bis 6063.Auf einemRechnerkonnenalsobis zu64–Server 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 außen zu einem unserer Server verbietenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\

-d $IPADDR 6000:6063 -j DENY -l


UDP–Diensteauf unpri vilegierten Ports

UDP bietet viel wenigerInformation fur dasBetreibeneinerFirewall, als TCP. Wir ha-benkeinerleiAnhaltspunkt,ob ein Paket eineClient–AnfrageodereineServer–Antwortist. Dasist naturlich geradebei denunprivilegiertenPortseinegroßeGefahr. Aus diesemGrundsolltenwir UDPganzlichsperrenundnureinzelneVerbindungenzuganzbestimm-tenRechnernzulassen.

Im unprivilegiertenBereichspieltzumGlucknureinwichtigerUDP–Diensteinerolle,dasNetwork File SystemNFS.NFSbenutztdenPort2049.NFSlasstsichzwar auchfur TCPkonfigurieren,aberdasist wesentlichunublicher, auchbeiTCPbenutztesdenPort2049.

In der Regel wird NFS ausschließlichim LAN benutzt,eineFirewall sollte eseigentlichselbstnicht brauchen.Wir sperrenalsodieNFS–Dienstevollig:

# 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\


ipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-d $ANYWHERE2049 -j DENY -l

6.4.6 Wichtige Diensteerlauben

NachdemunsereFirewall 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.

DNS

OhneDNS–ServerdienstewaredasInternet– undwohl heuteauchdie meistenIntranets–nicht zu gebrauchen.DNS ist alsoein Dienst,auf denwir keinesfalls verzichtenkonnen.Normalerweiselaufenalle DNS–AnfragenuberUDP, nur wenneineAntwort zu großfurein UDP–Paket ware,schicktderServerein gekurztesPaket andenClient zuruck,woraufderClient die gleicheAnfragenochmaluberTCPversuchenkann.In derPraxiswird dasseltenbenotigt. Fur denAbgleichderDatenzwischenprimarenundsekundarenNameser-verneinerZone(demsogenanntenZoneTransfer)wird allerdingsimmerTCPbenutzt.UmalsoPaketedurchunsereFirewall zu lassen,die eineUDP–Anfragebei unseremprimarenNameserverzugestatten,beschrankenwir unsaufdieseeineIP–AdressedesNameservers:

# DNS IP Adresse:NAMESERVER=xx.xx.xx.xx

# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\

-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT


Damit dasGanzeauch uber TCP funktioniert, insbesondere,damit ein eventuellerSe-kundarservereinenZone–Transferdurchfuhrenkann,benotigenwir nochzweiweitereRe-geln,diesmalfur TCP:

# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\


ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT

BeachtenSiehierdie Angabe! -y , diebesagt,daßdasACK–Flaggesetztseinmuß.

Wenn wir jetzt aberselbsteinenNameserver betreiben,und der in der Lage sein muß,sichmit einemubergeordnetenNameserver zu unterhalten,dannbrauchenwir nocheinenweiterenSatzRegeln.DieseKommunikationzwischenzwei Nameservernfindetnamlich– standardmaßig– 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 ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR 53 -j ACCEPT

Die letzteForm, die wir fur DNS nochbesprechenmussen,ist die Frage,ob auchClientsvon außerhalbauf unserenNameserver zugreifendurfen sollen.Das ist nur dannnotig,wenn wir tatsachlich eine echteDomain mit autoritativen Nameserver betreiben.In derRegel werdenwir denZugriff auf einenbestimmtenKreis von IP–Adressenbeschranken.Nennenwir diesenKreis malMYDNSCLIENTS.

# DNS Zugriff fremder ClientsMYDNSCLIENTS=ww.xx.yy.zz/mm

ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -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 ACCEPT


ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS53 \-d $IPADDR 53 -j ACCEPT

Fur densehrunwahrscheinlichenFall, daßSie einenZone–Transfervon außenzulassenwollen,gibt esnochdie Moglichkeit, auchdiesenmit Regelnzuzulassen.Allerdingssoll-ten wir hier die Liste der Clients, die diesenZone–Transferausfuhrendurfen wirklichnur auf die existierendenSekundarenServer von außenbeschranken,die diesenTransfertatsachlichbrauchen.Sonstkannjederalle DNS InformationenunsererDomaneeinfachfrei Hausbekommen...

# DNS Zone-Transfer fremder ClientsMYDNSZONECLIENTS=ww.xx.yy.zz/mm

ipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $MYDNSZONECLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $MYDNSZONECLIENTS$UNPRIVPORTS-j ACCEPT

Der identd–Service

Der identd –Dienst(manchmalauchauth genannt)lauft auf dem TCP–Port113. Erist fur viele anderenDienstezwingendnotwendig,etwa fur dasVersendenvon E-Mail.Der Server unseresRechnersstellt dabeiInformationenubereinenbestimmtenUserzurVerfugung,etwa,ob esdiesenUseruberhauptgibt.. . .

WennunserRechnereinenFTP–oderMailserverbetreibt,dannfungiertergleichzeitigim-merauchalsauth–Client.Esgibt keinensicherheitsrelevantenGrund,warumunserRech-nersocheAnfragennicht stellendurfte,alsolassenwir solcheAnfragenzu:

# abgehende auth-Anfragenipchains -A output -i $EXTERNAL_INTERFACE-p tcp\

-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE113 \-d $IPADDR $UNPRIVPORTS-j ACCEPT

Ob 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 ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\


-s $IPADDR 113 \-d $ANYWHERE$UNPRIVPORTS-j ACCEPT

Solltenwir unsgegendiesenDienstentscheiden,soist esin diesemeinzigenFall gunstiger,dasPaketmit REJECTstattmit DENY zubehandeln.AnsonstenentstehenhoheTimeout–Wartezeiten.Also:

# ankommende auth-Anfragen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-p tcp\

-s $ANYWHERE\-d $IPADDR 113 -j REJECT

Die 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 Amateur–Klasseverweist.Sie schutzt im Augenblicknamlichnur sichselbst.In dennachstenKapitelnwerdenwir dasandern.. .

Um unsereersteFirewall zu aktivieren,mußdasScript,daswir geradeerstellthabennurnoch ausfuhrbargemachtwerdenund aufgerufenwerden.Die Firewall lauft. Naturlichsollte dasin einemautomatisiertenStart–Script– je nachverwendeterDistribution – ge-schehen.

Kapitel 7

Die Fir ewall als Router insInter net

HeutesindlokaleNetzeetwasselbstverstandlichesgeworden,sowohl dieKostenfur solcheNetzehabensich dramatischnachuntenbewegt, als auchdasWissen,dasnotig ist, umComputerzuvernetzenist allgemeingestiegen.

AusdieserVerbreitungvonlokalenNetzenfolgertsehrschnellderWunsch,daßeinlokalesNetzeinenAnschlußansInternetfindet,ohnedaßjederRechnerubereinModemodereineISDN-Verbindungverfugenmuß.EsexistiereneinigeLosungsansatzefur diesesProblem,diezunachsteinmalkurzdargestelltwerdensollen:

7.1 Router oder Proxy

Die Begriffe Routerund Proxy werdengerneund oft falschoderzumindestensunscharfbenutzt.Dabeihandeltessich in beidenFallenum technischeLosungenfur dasProblemder AnbindungeineslokalenNetzesan dasInternet.Der Losungsansatzfindet jedochanvollig verschiedenenStellenstatt.

7.1.1 Die Proxy–Technik

Proxieswurden schonrelativ fruh eingesetzt,als Betreibervon einzelnenNetzenoderInternet–Providergemerkthatten,daßmancheWeb–Seitensehrhaufigaufgerufenwurden.Dasfuhrtezu der Idee,daßeinelokale Zwischenspeicherungdieserhaufig aufgerufenenWebseitendenDatenverkehrim Internetbzw. in derAnbindungzumInterneterheblichre-duzierenkonnte.DennanstatteineSeitepro Tag x mal uberdieseInternetanbindungzutransportieren,wurdesie nur nocheinmalgeholt, lokal zwischengespeichertund – fallsjemanddie AdressedieserSeiteaufrief – von diesemlokalen Zwischenspeicherherausausgeliefert.

Dasheißt,ein Proxy–Server 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.

46

7.1. ROUTERODERPROXY 47

Anwendung

Transport

Vermittlung

Netz

Anwendung

Transport

Vermittlung

Netz

Anwendung

Transport

Vermittlung

Netz

LAN Internet

Client ServerProxy

Bild 7.1: Die Proxy–Technik

DashatnundenNebeneffekt,daßeinProxy, dereineInternetanbindunghat,denRechnernim lokalenNetzaucheinenZugriff, zumindestensfur WWW–Seitenerlaubenkann,ohnedaßdie RechnerdeslokalenNetzesselbstZugangzum Internethaben.Sie erhaltenalleWebseitenja ebenvon diesemProxy. Der NachteildiesesVerfahrensliegt auf der Hand,einProxyarbeitetaufderAnwendungsschichtdesTCP/IPModellsundbietetnurFunktio-nalitatfur ein(odereinpaar)Protokoll(e).ModerneProxy–Systemegibt esetwafur WWWundFTP. DirekterInternet–Zugangist damitfur die Rechnerim Netznicht moglich.

Wasauf denerstenBlick wie ein Nachteilaussieht,kannaberauchgenausogewunschtsein.So ist esvorstellbar, daßein NetzbetreibereineslokalenNetzesgar nicht will, daßjederRechnerim LAN bedingungslosenZugriff ins Internetbekommt.Die notwendigenDienste,wie Mail, WWW und FTP konnenuberProxieszur Verfugunggestelltwerden,andereDienste,wie etwaNetzspieleuberdasInternetsindsonicht moglich.

7.1.2 Die Router–Technik

Im GegensatzzumProxyarbeitetein Router(oft auchGateway genannt)auf derVerbin-dungsschichtdesTCP/IPModells.Dasheißt,er gibt Pakete,die er erhalt unddie nicht furihn bestimmtsind,von einemNetzwerk–Interfacezu einemanderenweiter. Dabeiexistie-ren keineEinschrankungenhinsichtlich irgendwelcherProtokolle, dennProtokolle kenntderRouterja garnicht, fur ihn sindalle Paketenur IP–Pakete,egal wassieweiterenthal-ten.

Anwendung

Transport

Vermittlung

Netz

Anwendung

Transport

Vermittlung

Netz

Vermittlung

Netz

LAN Internet

Client Server

Router

Bild 7.2: Die Router–Technik

Die Arbeit einesRoutersim lokalenNetz,der zwei Netzemiteinanderverbindet,ist ein-fachzu verstehen.Dennder Routerkann ja klar sagen,welcheIP–Adressezu welchem

48 KAPITEL 7. DIE FIREWALL ALS ROUTERINS INTERNET

Netzgehort undwelchesNetzanwelcherSchnittstellehangt.WasausdiesemSatzschonklar wird – undwasein großerUnterschiedzumProxyist – ist die Tatsache,daßderRou-ter tatsachlichIP–Paketeweiterleitet.Dasist in einemlokalenNetzweiter kein Problem,wir werdenabergleichsehen,daßesim Zusammenhangmit demInternetsehrwohl zumProblemwerdenkann.

Im weiterenVerlauf interessiertunsnaturlich die Router–Technikim ZusammenhangmitderFirewall. Dabeiist esunsnaturlich unbenommen,auchProxy–Servereinzurichten,dieFunktionalitat derFirewall als Verbindungvom lokalenNetz ins InternetbasiertaberaufderWeitergabevon IP–Paketen,alsoauf demRouting.

7.2 DasProblemder reservierten Adr essen

In der gutenalten Zeit desInternets,als IP–Adressennoch nicht knappwarenund dieRechner, die ansNetz wollten dasubereineStandleitunggetanhaben,war dasRoutingim Netzein Kinderspiel.War dochdamalsdie Situationdie, daßjederansInternetange-schlosseneRechnereinefeste,einmaligeundvonuberallerreichbareIP–Adressehatte.EinRouterhattealsonurnochdieAufgabe,einPaketandieentsprechendrichtigeSchnittstelleauszuliefernundschonwar alleserledigt.

DieFirewall einesLinux RechnershatjanebendenbeidenRegelketteninput undoutputnochdie chain forward . DieseRegelkette ist speziellfur dasRoutinggedacht,dasoftauchmit demBegriff IP–forwardingbezeichetwird. Die Zusammenhangederdrei KettensindausdemBild auf Seite32 zu entnehmen.Mit Hilfe dieserRegelketteist esalsoauchnochmoglich,zuentscheiden,welchePaketegeroutetwerdensollen.

Heutejedochhabenwir eineKnappheitan IP–Adressenund die lokalenNetzelaufeninder Regel mit den sogenanntenreserviertenAdressen.DiesereserviertenAdressensindim Internetnicht routbar. Dasheißt,daßselbstwenneinerunsererRechneransInternetangeschlossenist unddiesereineRechneraucheineechteIP–Adresse1 hat,undnochdazualsRouterkonfiguriertist, eineVerbindungansInternetfur die anderenRechnernicht soohneweiteresmoglich ware.Die Rechnerim lokalenNetzhabenja IP–Adressen,die imInternetnicht gultig sind.Selbstwennein IP–Paket mit einersolchenungultigenAdressejemalseinenInternet–Server erreichenwurde,so waredieserRechnernicht in der LageeineAntwort zuruckzuschicken,dennesexistierenkeineRoutenzu reserviertenAdressen– wohin solltendie auchzeigen?Esgibt wahrscheinlichhundertevon lokalenNetzenaufderWelt, diedieseAdressenbenutzen.

1Besser:einenicht reservierte,alsoroutefahigeAdresse

7.3. MASQUERADING ALS PROBLEMLOSUNG 49

Internet

116.32.33.34

194.135.17.199

192.168.1.1

192.168.1.2

192.168.1.3

192.168.1.4 192.168.1.5

192.168.1.1 192.168.1.2 192.168.1.3 192.168.1.4

192.168.1.5

188.1.2.3

� �

! !"

# #$

% %&

' '( () )* + +, ,- -. .

/ / // / /0 0 00 0 01 12 2

3 3 34 4 4

5 5 55 5 56 6 66 6 67 78 8

9 9 9: : :

; ; ;; ; ;; ; ;< << <

= => >? ? ?@ @

AAAAAA

BBBBBB

CCCCC

DDDDD

EEEEE

FFFFF

Bild 7.3: ReservierteAdressenim Internet

7.3 MasqueradingalsProblemlosung

Der Linux–KernelbieteteineLosungsmoglichkeit fur dieVerwendungreservierterAdres-senim Internetan,dassogenannteMasquerading.DabeiarbeitetderRouter, alsoderRech-ner, dersowohl amlokalenNetz,alsauchamInternethangt,alsMasqueradingServer. Die-serRechnerhatja eineechte,im InternetroutfahigeAdresse.Er nimmt jetztausdemloka-len NetzPaketeentgegenundverandertsiedergestalt,daßim FeldderSenderIP–Adressejetzt nicht mehr die reservierteAdressedeswahrenAbsenderssteht,sonderndie echteAdressedesMasquerading–Servers.GleichzeitigmerktsichderMasqueradingServer dieOriginal–Adressein einer Kernel–Tabelle.Bekommt jetzt der MasqueradingServer dieAntwort ausdemInternet,so uberpruft er anhanddieserTabellen,fur wendieseAntwortwar, tauschtdie entsprechendenAdresenderPaketewiederum undgibt dassoveranderteAntwortpaketwiederandenRechnerim lokalenNetz,derdieAnfragelosgeschickthatte.

Aus der Sicht desInternet–Serversexistiert alsogar kein lokalesNetz, er kommuniziertausschließlichmit demMasqueradingServer. Die AdressendeslokalenNetzessindmas-kiert.Dashatnaturlich denschonerwahntenVorteil,daßAngriffeausdemInternetsowiesonuraufdenRouterstattfindenkonnen,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 durchdenBefehl

ipchains -A forward -i $EXTERNAL_INTERFACE-s 192.168.100.0/24 -j MASQ


dasMasqueradingfur 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,daßnurdiejenigenPakete,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 ewalls

Eine 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,dieBastion–Host–Firewall unddieDe-militarisierteZone(DMZ).

7.4.1 Die Bastion–Host–Firewall

Die einfachste– aberauchunsicherste– Form einerroutendenFirewall ist die Bastion–Host–Firewall. SiebestehtgrundsatzlichauseinemRechner, deralsdual homedhostzwi-schendemzuschutzendenNetzaufdereinenSeiteunddemunsicherenNetz(Internet)aufder anderenSeiteplaziert ist. DieserRechnerroutetPaketevon einemNetz ins andere–ob mit Masqueradingoderohne2. JedesPaket,dasdurchdiesenRechnergeroutetwerdensoll, mußdiedrei RegelkettenderFirewall durchlaufen.

Der Begriff Bastionstammtausdem Milit arischen,er kann aberauchwirklich so ver-standenwerden.Eine Bastionist eineVerteidigungseinrichtung,wennsie fallt, danngibteskeinenSchutzmehr. DieseAnalogiekannungebremstins Computernetubernommenwerden.Wenndie Bastion–Host–Firewall geknacktwerdenwurde,dannlagedasgesamteNetzschutzlosda,derAngreifer, derdie Firewall uberwundenhatte,kanim LAN tun undlassen,waser will.

Trotzdemist diesesModell fur die meistenkleinen Netzevollig ausreichend,wenndaszu schutzendeNetz nicht in großemMaß selbstDiensteim Internetanbietensoll. In derRegel ist dasaberja auchgar nicht moglich, dennnormalerweisewurdenwir in diesemModell sowiesomit reserviertenAdressenim lokalenNetzarbeiten– damithabenwir unsderMoglichkeit beraubt,selbstDiensteanzubieten.

2Ohnenaturlich nurdann,wenndaszuschutzendeNetzechte,routfahigeIP–Adressenbenutzt

7.4. VERSCHIEDENEMODELLE VON ROUTENDENFIREWALLS 51

Internet

Lokales (zu schützendes) Netz

Bastion−Host−Firewall

GHIJ KLM MN

O O OO O OO O OP P PP P PP P P

Q Q QR RS S ST T

UUUUUUUU

VVVVVVV

Bild 7.4: BastionHostFirewall

7.4.2 Die Demilitarisierte Zone (DMZ)

Erheblichsichererfur großeNetzeist dasModell der demilitarisiertenZone,manchmalauchPerimeterNetzwerkgenannt.DiesesModell trenntdaszu schutzendeNetz unddasoffentlichzugangigeNetznochmalaufundarbeitetfolgerichtigmit zweiFirewall–Rechnern.

DaslokaleNetz,dasdieeigentlichenArbeitsplatzeverbindet,ist weiterhindaszuschutzen-de Netz. ZwischendiesemlokalenNetz und der bosengroßenweitenWelt desInternetliegt jetztabernocheinNetz,diedemilitarisierteZone.Wir habenzweiFirewall–Rechner,einmalder Bastion–Host,der dasInternetmit der DMZ verbindet,und zum zweitendiesogenannteChoke–Firewall. SieverbindetdaszuschutzendeNetzmit derDMZ. Innerhalbder DMZ stehenjetzt die Rechner, die von außerhalbzuganglichseinsollen.Also etwaderWebserver desUnternehmens,derFTP–Server oderahnliches.Die RechnerderDMZmussendabeiabertatsachlichechte,routfahigeIP–Adressenbesitzen,damitdiesesModellfunktioniert.


Internet


Öffentliche Server

Choke−Firewall

Demilitarisierte Zone

Bastion−Host−Firewall

WWXX

YZ [[\\

] ]^ ^

_ _`a ab b

c c cc c cd dd de ef f

g g gh h

i ii ij jj jk k kl l l

m mn n

oooooo

ppppp

qqqqqq

rrrrrr

sssss

tttttt

uuuuu

Bild 7.5: DMZ Firewall

DieseForm 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,bestehendausBastion–Firewall, DMZ undChoke–Firewall.

Kapitel 8

ExemplarischerAufbau einerDMZ–Fir ewall

Um 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,daßBastionund Choke beideals Gateway (dual homedhost)zur DMZ dienen.Die DMZ enthalt offentlicheundhalboffentlicheServer. JedesNetzwer-kinterfaceder beidenFirewall–Rechner(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 mußesnocheinpaarseparateRegelngeben,wir gehenaberin diesemBeispieldavon aus,daßessichhierbeium 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.

53

54 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL

Internet


Öffentliche Server

Demilitarisierte Zone192.168.1.0

192.168.5.0

192.168.1.1192.168.1.2

192.168.5.1

eth1

eth0

eth1

Choke

Bastion

123.45.67.89eth0

v vv vw ww wxxyy

z z{| |} ~ ~��

� � ��

� � ��

� ��

� � ��

��

Bild 8.1: Der AufbaudesBeispiels

DasexterneInterfaceder Bastionliegt auf der Schnittstelleeth0 und hat die echteIP–Adresse123.45.67.89zugewiesen.DasinterneInterfaceliegt auf eth1 undhatdie reser-vierteAdresse192.168.1.1

Die DMZ hatdie192.168.1.0alsNetzwerkadresse.

Die Choke hatihr externesNetzamInterfaceeth0 unddort die Adresse192.168.1.2,ihrinternesNetzliegt auf eth1 undbekommtdieAdresse192.168.5.1

DasLAN hatdie Netzadresse192.168.5.0alsNetzwerkadresse.

8.1 Die symbolischenKonstanten

Ein Firewallscript lasstsich grundsatzlich leichter lesenund hauptsachlich flexibler anVeranderungenanpassen,wenn wir nicht bei jeder Regel erneutdie IP–Adressenange-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 Providers

8.2. WEITEREGRUNDEINSTELLUNGEN 55

BASTION_DMZ_INTERFACE=eth1 # internes InterfaceBASTION_DMZ_IPADDR=192.168.1.1 # Adresse dazu

LOOPBACK_INTERFACE=lo # Local LoopbackLOOPBACK=127.0.0.0/8 # Loopback-Adressbereich

CHOKE_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-Adresse

CLASS_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

8.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-Adressbereich

BASTION_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-Adresse


8.2 WeitereGrundeinstellungen

Wie ublich loschenwir zunachsteinmal in beidenScripts(fur Choke und Bastion)diebisherbestehendenRegeln.Dasist nur eineSicherheitsmaßnahme,um zu vermeiden,daß


eventuellexistierendeRegeln,die vor demAufruf desScriptserstelltwurden,nicht weitergelten.In beidenScriptsstehtalsojetzt


Die Chainssind jetzt geloscht,nicht jedocheineeventuellbestehendePolicy. Also defi-nierenwir soforteineneue,die allesgrundsatzlichverbietet,wasnicht explizit erlaubtist.Hier machenwir abereinenUnterschiedzwischenBastionundChoke.Die Bastionarbei-tet grundsatzlichmit DENY, gibt alsokeinerleiRuckmeldungenzuruck,außerins interneNetz,alsodie DMZ. Dasist wichtig, weil solcheRuckmeldungeneinempotenziellenAn-greiferschonbestimmteDingemitteilenkann.Die Chokejedocharbeitetin einemUmfeld,daswesentlichmehrVertrauenvon unsverdient.Hier arbeitenwir mit REJECT, um Feh-lermeldungenzuerzeugenundTimeout–Wartezeitendadurchzuvermeiden.DasScriptderBastionerhalt alsofolgendenEintrag:


wahrenddieChoke uberallmit REJECTarbeitet:

# Voreingestellte Policies setzenipchains -P input REJECTipchains -P output REJECTipchains -P forward REJECT

An diesemPunkt sind alle Regeln geloschtund alle Policiesauf DENY oder REJECTgesetzt.Esist keinerleiNetzverkehrmehrmoglich.Wie im letztenBeispielsolltenwir jetztzunachstwiederdasLoopback–Deviceermoglichen,dort sindAngriffe nicht moglich, esdrohtkeinerleiGefahr, wir lasseneinfachallesauf diesemDevice zu. Dasgilt wiederfurbeideMaschinen,BastionundChoke:


Es kannauchnicht schaden,wennwir an dieserStellewiederbei beidenMaschinendieKernel–eigenenSchutzroutinenaktivieren,wie wir dasauchschonim Abschnitt6.4.2ge-machthatten.Dort ist esschonerklart,daherhier nur nochdieentsprechendenAnweisun-gen:



echo 1 > $i

8.2. WEITEREGRUNDEINSTELLUNGEN 57

done

Jetztfiltern 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 -l

wahrenddieChoke 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 -l

Bei derBastionbelassenwir dieFilterungderrestlichenAdressenwie in unseremBeispielausAbschnitt6.4. Die Choke hingegenmußnur AdressenausdemPool der reserviertenA– undB–Klassenaussondern,weil sieja selbstaufbeidenNetzwerkkarteneineC–KlassereservierteAdressebenutzt.Nebenbeifiltern wir wie gehabtauchLoopback–und 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 verwerfen


ipchains -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

Damit hattenwir die Grundeinstellungbei beidenScriptserledigt. Jetztgeht es an dieeigentlicheArbeit, versprichtaberauchinteressanterzuwerden.

8.3 ICMP–Nachrichten filter n

Die Bastionhat schonRegeln fur ICMP–Nachrichten,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 Source–QuenchNachrichten

Die ICMP–Nachrichtenvom 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 ACCEPT

Die 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 ACCEPT

Sichtbarwird hier, daßdie Regeln fur Bastionund Choke sehrahnlich sind, aberebennur die fur die interneBastionSchnittstelleunddie derexternenChoke Schnittstelle.Dasist logisch,denndiesebeidenSchnittstellentransportierenja die InformationspaketevomLAN ins Internet.

8.3. ICMP–NACHRICHTENFILTERN 59

8.3.2 Parameter–Problem Nachrichten

DieseNachrichtenpakete(Typ 12)werdengesendet,wenneinPaketempfangenwurde,dasungultige Datenim Headeraufweist.Auch dieseNachrichtenlassenwir fur die Kommu-nikationmit derDMZ grundsatzlichdurch.


# 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


# 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

8.3.3 Destination–UnreachableNachrichten

DieserNachrichtenpakettyp(Typ 3) ist eineallgemeineFehlermeldung.AuchdieseNach-richtenlassenwir fur dieKommunikationmit derDMZ grundsatzlichdurch.


# destination-unreachable zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\




# destination-unreachable zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\



8.3.4 Time–ExceededNachrichten

DieseNachrichtenpakete(Typ 11)zeigenan,daßeinPaketzuoft geroutetwurde,daßseineLebensdauerauf 0 gesunken ist. Es wird aberauchals Antwort fur Traceroutebenutzt.Auch dieseNachrichtenlassenwir fur die Kommunikationmit der DMZ grundsatzlichdurch.



# time-exceeded zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\




Die 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 ACCEPT

8.3.5 Ping Konfiguration

DerBefehlping verwendetzweiunterschiedlicheNachrichtentypen,jeweilsfur Anfragen(echo-request – Typ 8) undAntworten(echo-reply – Typ 0).

ping Konfiguration der Bastion

Alle 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 ACCEPT

AndersherumdarfabernurdieBastionselbstRechnerin derDMZ anpingen:

# Ankommendes Ping in die DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\



ping Konfiguration der Choke

Die 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 ACCEPT

8.4. DIENSTEAUF UNPRIVILEGIERTEN PORTS 61

AnkommendePingssindjedochnurausderDMZ gestattet.

# Ankommende Pings aus der DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\



8.4 Diensteauf unpri vilegierten Ports

Die Diensteauf denunprivilegiertenPortslassenwir auf der Bastionso, wie wir sie imAbschnitt 6.4 formuliert hatte.Die Choke muß dieseDiensteuberhauptnicht beachten,dennes warenja nur Verboteausdem globalenNetz. Von außendroht 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 NameService

Das DNS–System(TCP– und UDP–Port53) ist heutefur eine Zugriff auf dasInternetvon zwingenderBedeutung.OhneNameserver musstendie IP–Addressender einzelnenServer im Internetbekanntsein,dasist mehroderwenigerunmoglich. Alle RechnerdesLAN mussenalsoZugriff auf einenNameserver haben.Dabeigibt esaberverschiedeneMoglichkeiten,diehier kurzbeschriebenwerdensollen.

8.5.1 Nutzung einesoffentlichen Nameservers

Die einfachsteForm ist die, daßein offentlicherNameserver im Internet,etwa der IhresProvidersbenutztwird. In diesemFall mußder Choke nur mitgeteilt werden,daßDNS–Anfragendurchgelassenwerden,so wie wir dasauchschonim Beispiel in Abschnitt6.4getanhaben.Die Bastionbehalt die Zeilen ausdemgenanntenBeispielebenfalls. Damitist ein Durchganggeschaffen,deralle notwendigenDNS–Diensteermoglicht. Die Chokeerhalt alsodie Zeilen:


# UDP-Nameserverzugriffipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\

-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPT

ipchains -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\


-d $NAMESERVER53 -j ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

Wir werdenjaspaterdasMasqueradingaktivieren,daherreichtes,wenndieAdresseimmernurdie derChoke ist. Alle AdressendesLAN werdenja in dieseAdressemaskiert.

8.5.2 BetreibeneigenerNameserver

Ein 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 greifenausschließlichauf die-senNameserver zu. Auch die Clientsder Bastion(die Programmeder Bastion,die einenDNS–Dienstbenotigen)greifenauf denServerderChoke zu.WennderChoke–Serverei-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 ACCEPT

ipchains -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 ACCEPT

ipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

ipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp\-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT

ipchains -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.xx

8.5. DOMAIN NAME SERVICE 63






ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT




# DNS Zugriff fremder Clientsipchains -A input -i $EXTERNAL_INTERFACE-p udp\


ipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPT

Konfiguration der Choke alspri vater Nameserver

DerprivateNameserver liegt aufderChoke.ClientsausdemLAN undderBastiongreifenauf diesenServer zu. Wenner eineAnfragenicht beantwortenkann,dannleitet er sie andenServerderBastionweiter.

Die Regeln fur die Choke verhaltensichgewissermaßenspiegelbildlich zu denenderBa-stion.

# Der DNS-Server der Choke gibt Anfragen an die Bastion (UDP 53)ipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\


ipchains -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 ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT

8.6 Der ident–Service (auth)

DieserService(TCP113)wird von manchenInternet–Dienstenbenutzt,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 eineFirewall–Regelerstellen,um unnotigeTimeoutszu vermeiden.

Fur unserBeispielwerdenwir davon ausgehen,daßsowohl 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\



# ankommende auth-Anfragen aus dem Internetipchains -A input -i $EXTERNAL_INTERFACE-p tcp\


ipchains -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 ACCEPT

ipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $DMZ_ADDRESSES113 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

8.7. E–MAIL 65

# Bastion als Server nach innenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \

-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR113 -j ACCEPT

ipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y\-s $BASTION_DMZ_IPADDR113 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT

8.6.2 Konfiguration der Choke

# Choke als auth Serveripchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \


ipchains -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 ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $ANYWHERE113 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

8.7 E–Mail

Esgibt naturlich – auchnur fur unserModell – eineVielzahlvon denkbarenKombinatio-nenfur E–Mail Empfangund Versand.Wir werdenhier exemplarischeineKombinationdurchspielen,die wahrscheinlichin der Praxisdie haufigsteist. Die Bastion,die ja eineechteIP–Adressehat, sendetund empfangtMail mit SMTP (TCP 25). Die RechnerdesLAN holensichdieMails beiderBastionmittelsPOP3(TCP110)ab.

Wir mussenalsoder BastionerlaubenSMTP–Paketezu empfangenund zu senden,undweiterhinPOP-Anfragenzu empfangenundzu beantworten.Die Choke mußauchSMTPdurchlassen,schließlichsendendie RechnerdesLAN ihre Mails ja mit SMTP. Sie mußebenfallsPOP–Paketedurchlassen,in beideRichtungen.

8.7.1 AbgehendeMails uber die Bastionverschicken

Hier 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 iel


ipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $SMTP_GATEWAY25 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $SMTP_GATEWAY25 \-d $IPADDR $UNPRIVPORTS-j ACCEPT

Wennaberstattdessenerwunschtist, daßdieBastionselbstMailserverist, alsodieMail di-rektzuverschicken,dannmußeinfachstattderAngabedesSMTP–Gatewaysein$ANYWHEREverwendetwerden:

# Mail uber SMTP an Provider Gatewayipchains -A output -i $EXTERNAL_INTERFACE-p tcp\


ipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE25 \-d $IPADDR $UNPRIVPORTS-j ACCEPT

DamitdieBastionaberauchankommendeAuftrageausderDMZ akzeptierenkann,bedarfesnocheinesweiterenRegelsatzesfur dasBastion–Script:

# Bastion nimmt SMTP Anfragen aus der DMZ entgegenipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \


ipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR25 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT

Jetztmussenwir abernochderChoke erlauben,SMTP-Paketeandie Bastiondurchzulas-sen.In dasChokeScriptmußfolglich 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 ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y\-s $BASTION_DMZ_IPADDR25 \-d CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

Damit solltederVersandvon E–Mail auchfur die Rechnerim LAN moglichsein.

8.7.2 Mailempfang uber POP–Server auf der Bastion

Die RechnerdesLAN holenihre Mails direkt bei derBastionab. Dasgeschiehtmit demPOP3Protokoll (TCP 110). Die Bastionmußnur Paketeausder DMZ durchlassen,ausdemInternetist dieserServicenichtverfugbar. DasBastion–ScriptbekommtalsonochdieRegeln:

# POP-Server der Bastion nimmt Pakete aus der DMZ entgegen

8.8. ALLE WEITERENDIENSTE 67

ipchains -A input -i $BASTION_DMZ_INTERFACE-p tcp \-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR110 -j ACCEPT

ipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

Naturlich mußjetztauchwiederdieChokenochsoweit konfiguriertwerden,daßsiePaketedurchlasst,die an die Bastiongerichtetsind. Das Choke–Scriptwird 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 ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

8.8 Alle weiteren Dienste

Damit wir hier jetzt nicht jedendenkbarenInternet–Dienstin 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 Choke

Bei 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 ACCEPT


8.10 Und schließlichdasMasquerading

Bis 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 sovonaußennicht ansprechbar)

DerersteSchritt ist jetztalsoder, daßwir dieBastionzumMasquerading–Servererklaren,der alle Pakete,die von der Choke kommen,auf seineechteInternet–Adressemaskiert.DasgesammteNetzwird sozumInternetkomplettversteckt.

# Bastion maskiert alle Pakete der Chokeipchains -A forward -i $EXTERNAL_INTERFACE\

-s $CHOKE_DMZ_IPADDRESS-j MASQ

Damit jetztaberauchallePaketeausdemLAN unterderAdressederChokeandieBastiongehen,mussenwir auchdie Choke als MasqueradingServer konfigurieren,die jetzt allePakete ausdem LAN mit ihrer DMZ–Adressemaskiert.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 MASQ

Anhang A

Wichtige Portnummern

A.1 Haufig gescanntePorts

Port Dienst Protokoll Gefahr Bemerkung

0 reserviert TCP/UDP hoch Sowohl als Absender–, als auch alsEmpfangerportungultig

0-5 TCP hoch Signaturvon sscan7 echo TCP/UDP hoch UDP–Angriffsmoglichkeit11 systat TCP hoch InformationenuberlaufendeProzesse15 netstat TCP hoch AbfragedesNetzwerkstatus,offeneVer-

bindungen,Routingtabellen,.. .19 chargen TCP/UDP hoch UDP–Angriffsmoglichkeit20,21 ftp TCP mittel FTP-Zugriff, Dateitransfer22 ssh TCP mittel Secure Shell – Eine sichere (ver-

schlusselte)Moglichkeit desremotelo-gin

22 UDP niedrig EinealteVersionvonPC–Anywhere23 telnet TCP hoch TELNET – UnverschlusselteMoglich-

keit desremotelogin25 smtp TCP hoch SimpleMail TransferProtocol– jemand

sucht nach Spam–Relayoder einer Si-cherheitslucke alterer sendmail Ver-sionen

53 domain TCP hoch TCP–Zone–TransferoderFalschungvonDNS–Informationen

67 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 drei

haufigstangegriffenenPorts111 sunrpc TCP/UDP hoch RemoteProcedureCall - Der haufigste

Angriffsportuberhaupt119 nntp TCP mittel Offentlicher Newsfeed(wird zum Ver-

sendenvon Spambenutzt)

TabelleA.1: HaufiggescanntePortnummernundihreBedeutung

69

70 ANHANG A. WICHTIGE PORTNUMMERN

Port Dienst Protokoll Gefahr Bemerkung

123 ntp UDP niedrig Zeitsynchronisationubers Netz - un-gefahrlichabervielleicht lastig

137 netbios-ns TCP/UDP mittel Nameservicefur Windows Netze – furUnix harmlos

138 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-griffsziele

161,162 snmp UDP mittel SimpleNetwork ManagementProtocol–NetzwerkadministrationubersNetz

177 xdmcp UDP hoch Login ManagerdesX-Window-Systems512 exec TCP hoch Remoteprocessexecution512 biff UDP hoch Mail–Benachrichtigung513 login TCP hoch RemoteLogin513 who UDP hoch Wer ist eingeloggt514 shell TCP hoch RemoteShell514 syslog UDP hoch SyslogEingang515 printer TCP hoch Netzwerk–Drucker517 talk UDP mittel Netzwerk–Telephon518 ntalk UDP mittel Netzwerk–Telephon520 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 aufs

Dateisystem5632 pcanywhere UDP niedrig PCAnywhere6000+n X11 TCP hoch X–Window–System12345 netbus TCP hoch NetBus,einTrojaner, derauchauf ande-

renPortserscheinenkann(haufigsindet-wa 12346oder20034)– fur Unix harm-los

31337 backorifice UDP hoch NocheinTrojaner– fur Unix harmlos

TabelleA.2: HaufiggescanntePortnummernundihre Bedeutung(Fortsetzung)

A.2. ICMP NACHRICHTENTYPEN 71

A.2 ICMP Nachrichten Typen

Name: Nummer: Bemerkung:

pong 0 Antwort auf Ping- auchecho-reply genanntdestination-unreachable 3 Fehlermeldung:Ein Router konnte das Paket nicht

weitergebenundsendetdieseMeldungzuruck.source-quench 4 Flusskontrollezwischenzwei Rechnernredirect 5 Routeninformation.Ein Rechner kann mit dieser

NachrichteinemanderenRechner(auf dementwederder routed oderder gated laufenmuß)mitteilen,daßeseinebessereRoutegibt.

ping 8 Echoanforderung.Ein Rechner, der dieses Paketerhalt, schickt eine Kopie desPaketeszuruck. Auchecho-request genannt

time-exceeded 11 Fehlermeldung:Paket wurdezu oft geroutet.DasLe-bensdauerfeldist auf 0

parameter-problem 12 Fehlermeldung:Der Headerdes IP–Paketes enthaltungultigeWerte

TabelleA.3: ICMP–Nachrichtentypen

Anhang B

Die Beispiel–Scripts

B.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






echo 1 > $idone

# Pakete ablehnen, die vorgeben von der eigenen Adresse zu stammen

72

B.1. DAS ERSTEFIREWALLSCRIPT 73

ipchains -A input -i $EXTERNAL_INTERFACE-s $IPADDR -j DENY -l






# 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


# 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 DENY

74 ANHANG B. DIE BEISPIEL–SCRIPTS

ipchains -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


















ipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE0 -d $IPADDR -j ACCEPT



















ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT



ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT




# DNS Zugriff fremder ClientsMYDNSCLIENTS=ww.xx.yy.zz/mm

ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -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 ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $MYDNSCLIENTS53 \-d $IPADDR 53 -j ACCEPT

# DNS Zone-Transfer fremder ClientsMYDNSZONECLIENTS=ww.xx.yy.zz/mm

ipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $MYDNSZONECLIENTS$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $IPADDR 53\-d $MYDNSZONECLIENTS$UNPRIVPORTS-j ACCEPT


# abgehende auth-Anfragenipchains -A output -i $EXTERNAL_INTERFACE-p tcp\



# ankommende auth-Anfragenipchains -A input -i $EXTERNAL_INTERFACE-p tcp\



# oder statt der letzten zwei Befehle# ankommende auth-Anfragen ablehnen# ipchains -A input -i $EXTERNAL_INTERFACE-p tcp\# -s $ANYWHERE\# -d $IPADDR 113 -j REJECT


B.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 Providers

BASTION_DMZ_INTERFACE=eth1 # internes InterfaceBASTION_DMZ_IPADDR=192.168.1.1 # Adresse dazu

LOOPBACK_INTERFACE=lo # Local LoopbackLOOPBACK=127.0.0.0/8 # Loopback-Adressbereich

CHOKE_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-Adresse







echo 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 -l

B.2. DAS BASTION FIREWALLSCRIPT 79






# 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


# 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 DENY


ipchains -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 außen# ICMP Typ 4 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\

















ipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE0 -d $IPADDR -j ACCEPT




# source-quench zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\



# parameter-problem zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\



# destination-unreachable zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\



# time-exceeded zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\



# 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 ACCEPT

# Ankommendes Ping in die DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\














# Der DNS-Server der Bastion akzeptiert Anfragen der Choke (UDP 53)ipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\


ipchains -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 ACCEPT

ipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\-s $CHOKE_DMZ_IPADDR53 \-d $BASTION_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

ipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp\-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT

ipchains -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.xx






ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT




# DNS Zugriff fremder Clients

ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -A output -i $EXTERNAL_INTERFACE-p udp\-s $IPADDR 53\-d $ANYWHERE$UNPRIVPORTS-j ACCEPT

ipchains -A input -i $EXTERNAL_INTERFACE-p tcp\-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j ACCEPT

ipchains -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\


ipchains -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\



# Bastion als auth-Client nach innenipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp \

-s $BASTION_DMZ_IPADDR$UNPRIVPORTS\-d $DMZ_ADDRESSES113 -j ACCEPT

ipchains -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 \


ipchains -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 iel

ipchains -A output -i $EXTERNAL_INTERFACE-p tcp\-s $IPADDR $UNPRIVPORTS\-d $SMTP_GATEWAY25 -j ACCEPT

ipchains -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 \


ipchains -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 \


ipchains -A output -i $BASTION_DMZ_INTERFACE-p tcp ! -y \-s $BASTION_DMZ_IPADDR110 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT


# Bastion maskiert alle Pakete der Chokeipchains -A forward -i $EXTERNAL_INTERFACE\

-s $CHOKE_DMZ_IPADDRESS-j MASQ


B.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-Adressbereich

BASTION_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-Adresse



# Voreingestellte Policies setzenipchains -P input REJECTipchains -P output REJECTipchains -P forward REJECT




echo 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 verwerfen

B.3. DAS CHOKE FIREWALLSCRIPT 87

ipchains -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\



# parameter-problem zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\



# destination-unreachable zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\



# 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 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\



# Der DNS-Server der Choke gibt Anfragen an die Bastion (UDP 53)ipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\


ipchains -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 \


ipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp \-s CHOKE_DMZ_IPADDR53 \-d $DMZ_ADDRESSES$UNPRIVPORTS-j ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT

ipchains -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 \


ipchains -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 ACCEPT

ipchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp ! -y \-s $ANYWHERE113 \-d $CHOKE_DMZ_IPADDR$UNPRIVPORTS-j ACCEPT

# Choke erlaubt SMTP-Pakete an die Bastion

B.3. DAS CHOKE FIREWALLSCRIPT 89

ipchains -A output -i $CHOKE_DMZ_INTERFACE-p tcp\-s CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPT

ipchains -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 \


ipchains -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 MASQ

Anhang C

Protokollbeschreibungen

Hier findenSiediewichtigstenProtokollbeschreibungenfur Diensteim Internet,mit derenHilfe eineFirewall beliebigaufgebautwerdenkann.DasFormatist immergleich,fur jedeZeile jederTabelleist eineipchains–Regelerforderlich.Die Beschreibungensindausfuhr-lich, nicht in jedemFall mussenalle Zeilenbeachtetwerden,aberfur alle Falle sind hierjeweilsdiegesammtenKommunikationswegedargestellt.

Die AngabenderAdressenbeziehensichnaturlich zunachstauf einesimpleein–Rechner–Firewall. Sollensiefur komplexereSituationendienen,somußanstellederAngabeADDRz.B. eineAdressangabefur einganzesNetzstehen.. .

90

C.1. DNS 91

C.1 DNS

Beschreibung Proto-koll

RemoteIP RemotePort Chain Local IP Local Port TCPFlags

Anfrageeineslo-kalenClients

UDP Nameserver 53 output IPADDR 1024:65535 –

Antwort desfremdenServers

UDP Nameserver 53 input IPADDR 1024:65535 –


TCP Nameserver 53 output IPADDR 1024:65535 Egal


TCP Nameserver 53 input IPADDR 1024:65535 ACK

Anfragedesloka-len Servers

UDP Nameserver 53 output IPADDR 53 oder an-dere

–


UDP Nameserver 53 input IPADDR 53 oder an-dere

–

Bitte um ZoneTransfer

TCP PrimarerNa-meserver

53 output IPADDR 1024:65535 Egal

Antwort auf BitteumZoneTransfer

TCP PrimarerNa-meserver

53 input IPADDR 1024:65535 ACK

Anfrage einesfremdenClients

UDP DNSClient 1024:65535 input IPADDR 53 –

Antwort desloka-len Servers

UDP DNSClient 1024:65535 output IPADDR 53 –


TCP DNSClient 1024:65535 input IPADDR 53 Egal


TCP DNSClient 1024:65535 output IPADDR 53 ACK

Anfrage einesfremdenServers

UDP DNSServer 53 oder an-dere

input IPADDR 53 –


UDP DNSServer 53 oder an-dere

output IPADDR 53 –

Jemandbittet umZoneTransfer

TCP SekundarerNameserver

1024:65535 input IPADDR 53 Egal

Antwort auf BitteumZoneTransfer

TCP SekundarerNameserver

1024:65535 output IPADDR 53 ACK

TabelleC.1:DasDNS–Protokoll

92 ANHANG C. PROTOKOLLBESCHREIBUNGEN

C.2 identd oder auth



Anfrage von lo-kalemClient

TCP ANYWHERE 113 output IPADDR 1024:65535 Egal

Antwort vonfremdemServer

TCP ANYWHERE 113 input IPADDR 1024:65535 ACK

Anfrage vonfremdemClient

TCP ANYWHERE 1024:65535 input IPADDR 113 Egal

Antwort von lo-kalemServer

TCP ANYWHERE 1024:65535 output IPADDR 113 ACK

TabelleC.2:Dasidentd–Protokoll

C.3 UsenetNews(NNTP)




TCP News Server 119 output IPADDR 1024:65535 Egal


TCP News Server 119 input IPADDR 1024:65535 ACK


TCP NNTPClient 1024:65535 input IPADDR 119 Egal


TCP NNTPClient 1024:65535 output IPADDR 119 ACK

Anfragedesloka-len Servers

TCP Newsfeed 119 output IPADDR 1024:65535:Egal


TCP Newsfeed 119 input IPADDR 1024:65535:ACK

TabelleC.3:DasNNTP–Protokoll

C.4. E-MAIL (SMTP/POP/IMAP) 93

C.4 E-Mail (SMTP/POP/IMAP)



AbgehendeMailsenden




AnkommendeMail empfangen




POP Anfrage ei-nes lokalen Cli-ents

TCP POPServer 110 output IPADDR 1024:65535 Egal

Antwort desfremden POPServers

TCP POPServer 110 input IPADDR 1024:65535 ACK

Anfrage einesfremden POPClients

TCP POPClient 1024:65535 input IPADDR 110 Egal

Antwort desloka-len POPServers

TCP POPClient 1024:65535 output IPADDR 110 ACK

IMAP Anfrageeines lokalenClients

TCP IMAP Server 143 output IPADDR 1024:65535 Egal


TCP IMAP Server 143 input IPADDR 1024:65535 ACK

Anfrage einesfremden IMAPClients

TCP IMAP Client 1024:65535 input IPADDR 143 Egal


TCP IMAP Client 1024:65535 output IPADDR 143 ACK

TabelleC.4:Die E-Mail Protokolle


C.5 Telnet








TCP TelnetClient 1024:65535 input IPADDR 23 Egal


TCP TelnetClient 1024:65535 output IPADDR 23 ACK

TabelleC.5:DasTelnet–Protokoll

C.6 Secure Shell (SSH)












TCP sshClients 1024:65535 input IPADDR 22 Egal


TCP sshClients 1024:65535 output IPADDR 22 ACK


TCP sshClients 513:1023 input IPADDR 22 Egal


TCP sshClients 513:1023 output IPADDR 22 ACK

TabelleC.6:DasSSH–Protokoll

C.7. FTP 95

C.7 FTP







Datenkanal Auf-bau vom frem-den Server, akti-verModus

TCP ANYWHERE 20 input IPADDR 1024:65535 Egal

Antwort auf Ka-nalaufbau durchlokalen Client,akt.Modus

TCP ANYWHERE 20 output IPADDR 1024:65535 ACK

Datenkanal Auf-bau zum frem-denServer, passi-verModus

TCP ANYWHERE 1024:65535 output IPADDR 1024:65535 Egal

Antwort auf Ka-nalaufbau durchfremden Server,passiver Modus

TCP ANYWHERE 1024:65535 input IPADDR 1024:65535 ACK





Datenkanal Auf-bauvomlok. Ser-ver, aktiver Mo-dus

TCP ANYWHERE 1024:65535 output IPADDR 20 Egal

Antwort auf Ka-nalaufbau durchfremden Client,akt.Modus

TCP ANYWHERE 1024:65535 input IPADDR 20 ACK

Datenkanal Auf-bauzumlok. Ser-ver, passiver Mo-dus

TCP ANYWHERE 1024:65535 input IPADDR 1024:65535 Egal

Antwort auf Ka-nalaufbau durchlok. Server, passi-verModus

TCP ANYWHERE 1024:65535 output IPADDR 1024:65535 ACK

TabelleC.7:DasFTP–Protokoll


C.8 HTTP - Normal











TabelleC.8:DasHTTP–Protokoll

C.9 HTTP - mit Secure Socket Layer (SSL)











TabelleC.9:DasHTTP/SSL–Protokoll

C.10 HTTP-Pr oxy Zugriff




TCP ProxyServer ProxyPort output IPADDR 1024:65535 Egal

Antwort desProxyServers

TCP ProxyServer ProxyPort input IPADDR 1024:65535 ACK

TabelleC.10:DasWeb–Proxy–Protokoll

Firewallaufbau mit Linux - Linux-Praxis · PDF fileKapitel 1 Vorwort Die vorliegende Dokumentation beschreibt Funktionsweise, Aufbau und Wartung eines Firewallrechners unter Linux

Text of Firewallaufbau mit Linux - Linux-Praxis · PDF fileKapitel 1 Vorwort Die vorliegende...

Linux-Kurs · Linux hat große Marktanteile im Server- und Smartphone-Segment Es gibt hunderte von Linux-Distributionen Die meist verbreiteten sind: Debian, Ubuntu, Linux Mint, Fedora,

Linux Befehle fuer die Konsole - poct5i36suhgcw9b.myfritz.netpoct5i36suhgcw9b.myfritz.net/netz/netzwerke/Linux-Befehle.pdf · Linux Befehle fuer die Konsole Rupert Wenzel Aktuelle

Linux Administrator Volker Neumann, LINUX - 13 Linux-Certificates

Die Funktionsweise der Geldschöpfung

Linux Befehle

Linux I - cl.uni-heidelberg.de€¦ · Linux I 1 Linux I Theorie Terminal Ein- und Ausgabe Ressourcen-Vorkurs. Linux IIIIIIRes/ProWN/TT TheorieTerminalEin- und Ausgabe Theorie Linux

Debian GNU/Linux – Installationsanleitung · 2021. 2. 1. · KAPITEL1. WILLKOMMENBEIDEBIAN 1.2. WASISTGNU/LINUX? 1.2 WasistGNU/Linux? LinuxisteinBetriebssystem-eineReihevonProgrammen,dieesIhnenermöglichen

Basiskurs Linux

Pumpspeicherkraftwerke. Aufbau der Präsentation Was sind Pumpspeicherkraftwerke? Was sind Pumpspeicherkraftwerke? Funktionsweise Funktionsweise Erläuterung

Arch Linux

Wirksamkeitsbericht bestätigt gute Funktionsweise des

Grundlagen Verbrennungsmotoren : Funktionsweise ... · GünterP. Merker • RüdigerTeichmann Herausgeber Grundlagen Verbrennungsmotoren Funktionsweise, Simulation, Messtechnik 7.,

Effizientes Linux System Management · Effizientes Linux System Management Marcel Härry Linux System Engineer /sys - Puzzle ITC puzzle.ch

Linux Python

Sicherheit von Linux-Systemen - uni-muenster.de · Sicherheit von Linux-Systemen Sicherheit von Linux-Systemen Konﬁguration von SuSE Linux Professional 9.3 Christian Muck-Lichtenfeld

Linux – eine Einführung Geschichte Distributionen Ubuntu-Linux Installation von Ubuntu-Linux Erste Schritte Verwendung in der Schule Edubuntu-Linux Probleme

Pendelrampen â€“ Funktionsweise und Erfahrungen

Linux Basiswissen

Funktionsweise des RSA-Verfahrens

Wie komme ich zu einem Embedded-Linux-System? - linuxtag.orglinuxtag.org/2013/fileadmin/ · Embedded-Linux-System 1 Aufbau — Embedded-Linux 2 Toolchain 3 JTAG und OpenOCD 4 Linux-Kernel

Computer-Netzwerke – Grundlagen, Funktionsweise, Anwendung

Peripheriegeräte Erkennen und Funktionsweise

Linux Printer Driver Manualdownload.brother.com/pub/jp/j-ptouch/download2/linux/...Mandriva Linux 2006 Red Hat Linux 9 SuSE Linux 10.0 MIRACLE Linux V4.0 Turbolinux 10 FUJI Vine Linux

OFFSHORE WIND SCHWERKRAFTFUNDAMENTE - bfn.de · Monopile Tripod Jacket Gravity Base Floating OFFSHORE WIND SCHWERKRAFTFUNDAMENTE FUNKTIONSWEISE FUNKTIONSWEISE

Linux- Dirk Frettl oh Vorlesung Linux-Praktikum

Die Brennstoffzelle Von Lars Callies. Die Brennstoffzelle Geschichte Geschichte Einordnung Einordnung Funktionsweise Funktionsweise Chemische Reaktionen

nftables–DerneuePaketﬁlterim Linux-Kernel · nftables–DerneuePaketﬁlterim Linux-Kernel CLT201415.März2014 Michael Steinfurth Linux/Unix Consultant & Trainer B1 Systems GmbH

Linux UNIX. Gliederung 1. Entstehung von UNIX 2. Aufbau von UNIX 3. Was ist Linux? 4. Eigenschaften des Linux-Kernels 5. Linux-Distributionen 6. Rechte

Einführung in Linux Mint · 2016. 9. 15. · Linux Mint 18 „Sarah ... Installation von Linux Mint KDE Du kannst das Linux Mint Betriebssystem kostenlos herunter laden. Im Falle

Inhaltsverzeichnis Geschichte Funktionsweise Einsatzbereiche · Kevin Kubulek Martin Tenschert Inhaltsverzeichnis Geschichte Funktionsweise Einsatzbereiche Forschung Verbesserte Methoden

Documents

Firewallaufbau mit Linux - Linux-Praxis · PDF fileKapitel 1 Vorwort Die vorliegende Dokumentation beschreibt Funktionsweise, Aufbau und Wartung eines Firewallrechners unter Linux

Text of Firewallaufbau mit Linux - Linux-Praxis · PDF fileKapitel 1 Vorwort Die vorliegende...