Upload
trannhu
View
218
Download
1
Embed Size (px)
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:
10 KAPITEL 2. GRUNDLAGEN
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. DAS TCP/IPREFERENZMODELL 11
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)
12 KAPITEL 2. GRUNDLAGEN
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
2.2. DAS TCP/IPREFERENZMODELL 13
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
Die BedeutungdereinzelnenFelderist
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.
14 KAPITEL 2. GRUNDLAGEN
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
Die BedeutungdereinzelnenFelderist
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
16 KAPITEL 2. GRUNDLAGEN
mit demClient.Er schicktjetzteinPaketzuruck,dassowohl dasACK–Flag(Acknowledge– Bestatigung),alsauchwiederumein SYN–Flaggesetzthat.Man sprichtjetzt von einerhalb–offenenVerbindung.
Web−ServerWorkstation mit Browser
IP−Adr.: 123.45.67.89 IP−Adr.: 10.11.12.13Port 12345 Port 80
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
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: 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
34 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX
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.
36 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX
� /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
6.4. PRAKTISCHERAUFBAU EINERFIREWALL 37
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.*.*.*
38 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX
� 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
6.4. PRAKTISCHERAUFBAU EINERFIREWALL 39
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:
40 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX
# ICMP Typ 12 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE12 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 12 -d $ANYWHERE-j ACCEPT
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\
-s $ANYWHERE3 -d $IPADDR -j ACCEPT
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\
-s $ANYWHERE11 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 11 -d $MY_ISP -j ACCEPT
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\
6.4. PRAKTISCHERAUFBAU EINERFIREWALL 41
-s $ANYWHERE0 -d $IPADDR -j ACCEPT
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
42 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX
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\
-d $IPADDR 2049 -j DENY -l
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
6.4. PRAKTISCHERAUFBAU EINERFIREWALL 43
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\
-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPT
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
44 KAPITEL 6. GESTALTUNG EINERFIREWALL MIT LINUX
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\
6.4. PRAKTISCHERAUFBAU EINERFIREWALL 45
-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
50 KAPITEL 7. DIE FIREWALL ALS ROUTERINS INTERNET
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.
52 KAPITEL 7. DIE FIREWALL ALS ROUTERINS INTERNET
Internet
Lokales (zu schützendes) Netz
Ö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
Lokales (zu schützendes) Netz
Ö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
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.2 WeitereGrundeinstellungen
Wie ublich loschenwir zunachsteinmal in beidenScripts(fur Choke und Bastion)diebisherbestehendenRegeln.Dasist nur eineSicherheitsmaßnahme,um zu vermeiden,daß
56 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
eventuellexistierendeRegeln,die vor demAufruf desScriptserstelltwurden,nicht weitergelten.In beidenScriptsstehtalsojetzt
# Alle bestehenden Regeln l oschenipchains -F
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:
# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECT
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:
# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT
Es kannauchnicht schaden,wennwir an dieserStellewiederbei beidenMaschinendieKernel–eigenenSchutzroutinenaktivieren,wie wir dasauchschonim Abschnitt6.4.2ge-machthatten.Dort ist esschonerklart,daherhier nur nochdieentsprechendenAnweisun-gen:
# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies
# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdo
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
58 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
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.
Die Befehlefur die Bastion
# parameter-problem zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $ANYWHERE12 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES12 -d $ANYWHERE-j ACCEPT
Die Befehlefur die Choke
# parameter-problem zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $ANYWHERE12 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR12 -d $ANYWHERE-j ACCEPT
8.3.3 Destination–UnreachableNachrichten
DieserNachrichtenpakettyp(Typ 3) ist eineallgemeineFehlermeldung.AuchdieseNach-richtenlassenwir fur dieKommunikationmit derDMZ grundsatzlichdurch.
Die Befehlefur die Bastion
# destination-unreachable zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $ANYWHERE3 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES3 -d $ANYWHERE-j ACCEPT
Die Befehlefur die Choke
# destination-unreachable zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $ANYWHERE3 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR3 -d $ANYWHERE-j ACCEPT
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.
60 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
Die Befehlefur die Bastion
# time-exceeded zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $BASTION_DMZ_IPADDR11 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES11 -d $BASTION_DMZ_IPADDR-j ACCEPT
Die Befehlefur die Choke
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\
-s $BASTION_DMZ_IPADDR8 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES0 -d $BASTION_DMZ_IPADDR-j ACCEPT
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\
-s $DMZ_ADDRESSES8 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR0 -d $DMZ_ADDRESSES-j ACCEPT
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:
# DNS IP Adresse:NAMESERVER=xx.xx.xx.xx
# UDP-Nameserverzugriffipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\
-s $CHOKE_DMZ_IPADDR$UNPRIVPORTS\-d $NAMESERVER53 -j 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\
62 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
-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
#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
# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT
# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT
# DNS Zugriff fremder Clientsipchains -A input -i $EXTERNAL_INTERFACE-p udp\
-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 53 -j 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
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\
-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j ACCEPT
ipchains -A input -i $CHOKE_DMZ_INTERFACE-p udp\-s $BASTION_DMZ_IPADDR53\-d $CHOKE_DMZ_IPADDR53 -j ACCEPT
64 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
# 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\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPT
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\
-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
# 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 \
-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR113 -j ACCEPT
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
66 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
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\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE25 -j ACCEPT
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 \
-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPT
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
68 KAPITEL 8. EXEMPLARISCHERAUFBAU EINERDMZ–FIREWALL
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
# Alle bestehenden Regeln l oschenipchains -F
# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECT
# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT
# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies
# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdo
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
# Reservierte A-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENY
# Reservierte B-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENY
# Reservierte C-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENY
# Pakete mit Loopback als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENY
# Pakete mit illegalen Broadcast Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $BROADCAST_DEST-j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $BROADCAST_SRC-j DENY
# Pakete mit Klasse-D Adresse als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_D -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_D -j
# Klasse-E Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_E -j DENY
# Von der IANA reservierte Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s 1.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 2.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 5.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 7.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 23.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 27.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 31.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 37.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 39.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 41.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 42.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 58.0.0.0/7 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 60.0.0.0/8 -j DENY# 65 entspricht 01000001 - also wurde die Maske /3 leider die 64# mit ansprechen. Wir mussen daher 65-79 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 65.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 66.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 67.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 68.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 69.0.0.0/8 -j 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
# 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
# ICMP Typ 12 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE12 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 12 -d $ANYWHERE-j ACCEPT
# ICMP-Typ 3 f ur Providerrechner erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE3 -d $IPADDR -j ACCEPT
B.1. DAS ERSTEFIREWALLSCRIPT 75
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
# ICMP-Typ 11 erlauben (ausgehend nur an unseren Provider)ipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE11 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 11 -d $MY_ISP -j ACCEPT
# Ausgehendes Ping erlaubenipchain -A output -i $EXTERNAL_INTERFACE-p icmp\
-s $IPADDR 8 -d $ANYWHERE-j ACCEPT
ipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE0 -d $IPADDR -j ACCEPT
# Ankommendes Ping nur f ur Provider erlaubenipchain -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $MYISP 8 -d $IPADDR -j ACCEPT
ipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 0 -d $MYISP -j ACCEPT
# Open Window Verbindungsaufbau sperrenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\
-s $IPADDR -d $ANYWHERE2000 -j REJECT
# X11 Aufbau zu einem fremden Server verbietenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\
-s $IPADDR -d $ANYWHERE6000:6063 -j REJECT
# X11 Aufbau von außen zu einem unserer Server verbietenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\
-d $IPADDR 6000:6063 -j DENY -l
# NFS (2049) uber UDP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p udp\
-d $IPADDR 2049 -j DENY -l
# NFS (2049) uber TCP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\
-d $IPADDR 2049 -j DENY -l
ipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-d $ANYWHERE2049 -j DENY -l
# DNS IP Adresse:NAMESERVER=xx.xx.xx.xx
# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\
76 ANHANG B. DIE BEISPIEL–SCRIPTS
-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT
# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\
-s $IPADDR $UNPRIVPORTS\-d $NAMESERVER53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $NAMESERVER53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT
#DNS Forwarding (Server zu Server)ipchains -A output -i $EXTERNAL_INTERFACE-p udp\
-s $IPADDR 53 \-d $NAMESERVER53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $NAMESERVER53 \-d $IPADDR 53 -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
B.1. DAS ERSTEFIREWALLSCRIPT 77
# 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
# 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
# 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
78 ANHANG B. DIE BEISPIEL–SCRIPTS
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
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
# Alle bestehenden Regeln l oschenipchains -F
# Voreingestellte Policies setzenipchains -P input DENYipchains -P output REJECTipchains -P forward REJECT
# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT
# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies
# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdo
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
# Reservierte A-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_A -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_A -j DENY
# Reservierte B-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_B -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_B -j DENY
# Reservierte C-Klasse Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_C -j DENYipchains -A output -i $EXTERNAL_INTERFACE-d $CLASS_C -j DENY
# Pakete mit Loopback als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $LOOPBACK-j DENY
# Pakete mit illegalen Broadcast Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $BROADCAST_DEST-j DENYipchains -A input -i $EXTERNAL_INTERFACE-d $BROADCAST_SRC-j DENY
# Pakete mit Klasse-D Adresse als Absender verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_D -j DENYipchains -A output -i $EXTERNAL_INTERFACE-s $CLASS_D -j
# Klasse-E Adressen ablehnenipchains -A input -i $EXTERNAL_INTERFACE-s $CLASS_E -j DENY
# Von der IANA reservierte Adressen verwerfenipchains -A input -i $EXTERNAL_INTERFACE-s 1.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 2.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 5.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 7.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 23.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 27.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 31.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 37.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 39.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 41.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 42.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 58.0.0.0/7 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 60.0.0.0/8 -j DENY# 65 entspricht 01000001 - also wurde die Maske /3 leider die 64# mit ansprechen. Wir mussen daher 65-79 einzeln angebenipchains -A input -i $EXTERNAL_INTERFACE-s 65.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 66.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 67.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 68.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 69.0.0.0/8 -j DENYipchains -A input -i $EXTERNAL_INTERFACE-s 70.0.0.0/8 -j DENY
80 ANHANG B. DIE BEISPIEL–SCRIPTS
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\
-s $ANYWHERE4 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 4 -d $ANYWHERE-j ACCEPT
# ICMP Typ 12 erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE12 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 12 -d $ANYWHERE-j ACCEPT
# ICMP-Typ 3 f ur Providerrechner erlaubenipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE3 -d $IPADDR -j ACCEPT
B.2. DAS BASTION FIREWALLSCRIPT 81
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
# ICMP-Typ 11 erlauben (ausgehend nur an unseren Provider)ipchains -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $ANYWHERE11 -d $IPADDR -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 11 -d $MY_ISP -j ACCEPT
# Ausgehendes Ping erlaubenipchain -A output -i $EXTERNAL_INTERFACE-p icmp\
-s $IPADDR 8 -d $ANYWHERE-j ACCEPT
ipchain -A input -i $EXTERNAL_INTERFACE-p icmp\-s $ANYWHERE0 -d $IPADDR -j ACCEPT
# Ankommendes Ping nur f ur Provider erlaubenipchain -A input -i $EXTERNAL_INTERFACE-p icmp\
-s $MYISP 8 -d $IPADDR -j ACCEPT
ipchain -A output -i $EXTERNAL_INTERFACE-p icmp\-s $IPADDR 0 -d $MYISP -j ACCEPT
# source-quench zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $BASTION_DMZ_IPADDR4 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES4 -d $BASTION_DMZ_IPADDR-j ACCEPT
# parameter-problem zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $ANYWHERE12 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES12 -d $ANYWHERE-j ACCEPT
# destination-unreachable zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $ANYWHERE3 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES3 -d $ANYWHERE-j ACCEPT
# time-exceeded zur DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $BASTION_DMZ_IPADDR11 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES11 -d $BASTION_DMZ_IPADDR-j ACCEPT
# Ausgehendes Ping aus der DMZipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES8 -d $ANYWHERE-j ACCEPTipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
82 ANHANG B. DIE BEISPIEL–SCRIPTS
-s $ANYWHERE0 -d $DMZ_ADDRESSES-j ACCEPT
# Ankommendes Ping in die DMZipchains -A output -i $BASTION_DMZ_INTERFACE-p icmp\
-s $BASTION_DMZ_IPADDR8 -d $DMZ_ADDRESSES-j ACCEPTipchains -A input -i $BASTION_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES0 -d $BASTION_DMZ_IPADDR-j ACCEPT
# Open Window Verbindungsaufbau sperrenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\
-s $IPADDR -d $ANYWHERE2000 -j REJECT
# X11 Aufbau zu einem fremden Server verbietenipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\
-s $IPADDR -d $ANYWHERE6000:6063 -j REJECT
# X11 Aufbau von außen zu einem unserer Server verbietenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\
-d $IPADDR 6000:6063 -j DENY -l
# NFS (2049) uber UDP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p udp\
-d $IPADDR 2049 -j DENY -l
# NFS (2049) uber TCP sperrenipchains -A input -i $EXTERNAL_INTERFACE-p tcp -y\
-d $IPADDR 2049 -j DENY -l
ipchains -A output -i $EXTERNAL_INTERFACE-p tcp -y\-d $ANYWHERE2049 -j DENY -l
# Der DNS-Server der Bastion akzeptiert Anfragen der Choke (UDP 53)ipchains -A input -i $BASTION_DMZ_INTERFACE-p udp\
-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j 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):
B.2. DAS BASTION FIREWALLSCRIPT 83
NAMESERVER=xx.xx.xx.xx
#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
# UDP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p udp\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p udp\-s $ANYWHERE53 \-d $IPADDR $UNPRIVPORTS-j ACCEPT
# TCP-Nameserverzugriffipchains -A output -i $EXTERNAL_INTERFACE-p tcp\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-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\
-s $IPADDR $UNPRIVPORTS\-d $ANYWHERE113 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE-p tcp ! -y\-s $ANYWHERE113 \
84 ANHANG B. DIE BEISPIEL–SCRIPTS
-d $IPADDR $UNPRIVPORTS-j ACCEPT
# ankommende auth-Anfragen aus dem Internetipchains -A input -i $EXTERNAL_INTERFACE-p tcp\
-s $ANYWHERE$UNPRIVPORTS\-d $IPADDR 113 -j ACCEPT
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
# 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
# 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 \
-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $BASTION_DMZ_IPADDR25 -j ACCEPT
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 \
-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
B.2. DAS BASTION FIREWALLSCRIPT 85
# Bastion maskiert alle Pakete der Chokeipchains -A forward -i $EXTERNAL_INTERFACE\
-s $CHOKE_DMZ_IPADDRESS-j MASQ
86 ANHANG B. DIE BEISPIEL–SCRIPTS
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
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
# Alle bestehenden Regeln l oschenipchains -F
# Voreingestellte Policies setzenipchains -P input REJECTipchains -P output REJECTipchains -P forward REJECT
# Loopback ohne Einschr ankungenipchains -A input -i $LOOPBACK_INTERFACE-j ACCEPTipchains -A output -i $LOOPBACK_INTERFACE-j ACCEPT
# SYN_COOKIESaktivierenecho 1 > /proc/sys/net/ipv4/tcp_syncookies
# SOURCEADDRESSVERIFICATION aktivierenfor i in /proc/sys/net/ipv4/conf/*/rp_filterdo
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\
-s $DMZ_ADDRESSES4 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR4 -d $DMZ_ADDRESSES-j ACCEPT
# parameter-problem zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $ANYWHERE12 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR12 -d $ANYWHERE-j ACCEPT
# destination-unreachable zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $ANYWHERE3 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR3 -d $ANYWHERE-j ACCEPT
# time-exceeded zur DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
88 ANHANG B. DIE BEISPIEL–SCRIPTS
-s $BASTION_DMZ_IPADDR11 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR11 -d $BASTION_DMZ_IPADDR-j ACCEPT
# Ausgehendes Ping ins Internetipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR8 -d $ANYWHERE-j ACCEPTipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $ANYWHERE0 -d $CHOKE_DMZ_IPADDR-j ACCEPT
# Ankommende Pings aus der DMZipchains -A input -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $DMZ_ADDRESSES8 -d $CHOKE_DMZ_IPADDR-j ACCEPTipchains -A output -i $CHOKE_DMZ_INTERFACE-p icmp\
-s $CHOKE_DMZ_IPADDR0 -d $DMZ_ADDRESSES-j ACCEPT
# Der DNS-Server der Choke gibt Anfragen an die Bastion (UDP 53)ipchains -A output -i $CHOKE_DMZ_INTERFACE-p udp\
-s $CHOKE_DMZ_IPADDR53\-d $BASTION_DMZ_IPADDR53 -j ACCEPT
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
# Choke als auth Serveripchains -A input -i $CHOKE_DMZ_INTERFACE-p tcp \
-s $DMZ_ADDRESSES$UNPRIVPORTS\-d $CHOKE_DMZ_IPADDR113 -j ACCEPT
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 \
-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
# 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 –
Anfrageeineslo-kalenClients
TCP Nameserver 53 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP Nameserver 53 input IPADDR 1024:65535 ACK
Anfragedesloka-len Servers
UDP Nameserver 53 output IPADDR 53 oder an-dere
–
Antwort desfremdenServers
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 –
Anfrage einesfremdenClients
TCP DNSClient 1024:65535 input IPADDR 53 Egal
Antwort desloka-len Servers
TCP DNSClient 1024:65535 output IPADDR 53 ACK
Anfrage einesfremdenServers
UDP DNSServer 53 oder an-dere
input IPADDR 53 –
Antwort desloka-len Servers
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
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
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)
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP News Server 119 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP News Server 119 input IPADDR 1024:65535 ACK
Anfrage einesfremdenClients
TCP NNTPClient 1024:65535 input IPADDR 119 Egal
Antwort desloka-len Servers
TCP NNTPClient 1024:65535 output IPADDR 119 ACK
Anfragedesloka-len Servers
TCP Newsfeed 119 output IPADDR 1024:65535:Egal
Antwort desfremdenServers
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)
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
AbgehendeMailsenden
TCP ANYWHERE 25 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP ANYWHERE 25 input IPADDR 1024:65535 ACK
AnkommendeMail empfangen
TCP ANYWHERE 1024:65535 input IPADDR 25 Egal
Antwort desloka-len Servers
TCP ANYWHERE 1024:65535 output IPADDR 25 ACK
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
Antwort desfremdenServers
TCP IMAP Server 143 input IPADDR 1024:65535 ACK
Anfrage einesfremden IMAPClients
TCP IMAP Client 1024:65535 input IPADDR 143 Egal
Antwort desloka-len Servers
TCP IMAP Client 1024:65535 output IPADDR 143 ACK
TabelleC.4:Die E-Mail Protokolle
94 ANHANG C. PROTOKOLLBESCHREIBUNGEN
C.5 Telnet
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP ANYWHERE 23 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP ANYWHERE 23 input IPADDR 1024:65535 ACK
Anfrage einesfremdenClients
TCP TelnetClient 1024:65535 input IPADDR 23 Egal
Antwort desloka-len Servers
TCP TelnetClient 1024:65535 output IPADDR 23 ACK
TabelleC.5:DasTelnet–Protokoll
C.6 Secure Shell (SSH)
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP ANYWHERE 22 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP ANYWHERE 22 input IPADDR 1024:65535 ACK
Anfrageeineslo-kalenClients
TCP ANYWHERE 22 output IPADDR 513:1023 Egal
Antwort desfremdenServers
TCP ANYWHERE 22 input IPADDR 513:1023 ACK
Anfrage einesfremdenClients
TCP sshClients 1024:65535 input IPADDR 22 Egal
Antwort desloka-len Servers
TCP sshClients 1024:65535 output IPADDR 22 ACK
Anfrage einesfremdenClients
TCP sshClients 513:1023 input IPADDR 22 Egal
Antwort desloka-len Servers
TCP sshClients 513:1023 output IPADDR 22 ACK
TabelleC.6:DasSSH–Protokoll
C.7. FTP 95
C.7 FTP
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP ANYWHERE 21 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP ANYWHERE 21 input IPADDR 1024:65535 ACK
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
Anfrage einesfremdenClients
TCP ANYWHERE 1024:65535 input IPADDR 21 Egal
Antwort desloka-len Servers
TCP ANYWHERE 1024:65535 output IPADDR 21 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
96 ANHANG C. PROTOKOLLBESCHREIBUNGEN
C.8 HTTP - Normal
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP ANYWHERE 80 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP ANYWHERE 80 input IPADDR 1024:65535 ACK
Anfrage einesfremdenClients
TCP ANYWHERE 1024:65535 input IPADDR 80 Egal
Antwort desloka-len Servers
TCP ANYWHERE 1024:65535 output IPADDR 80 ACK
TabelleC.8:DasHTTP–Protokoll
C.9 HTTP - mit Secure Socket Layer (SSL)
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP ANYWHERE 443 output IPADDR 1024:65535 Egal
Antwort desfremdenServers
TCP ANYWHERE 443 input IPADDR 1024:65535 ACK
Anfrage einesfremdenClients
TCP ANYWHERE 1024:65535 input IPADDR 443 Egal
Antwort desloka-len Servers
TCP ANYWHERE 1024:65535 output IPADDR 443 ACK
TabelleC.9:DasHTTP/SSL–Protokoll
C.10 HTTP-Pr oxy Zugriff
Beschreibung Proto-koll
RemoteIP RemotePort Chain Local IP Local Port TCPFlags
Anfrageeineslo-kalenClients
TCP ProxyServer ProxyPort output IPADDR 1024:65535 Egal
Antwort desProxyServers
TCP ProxyServer ProxyPort input IPADDR 1024:65535 ACK
TabelleC.10:DasWeb–Proxy–Protokoll